Having tests not be order dependent is good for cases where you only want to run one test in a file. (There’s a thing people say about wanting all tests to run in some small total time. I think it’s ok for smoke tests – that is, tests that connect everything together and show that the magic smoke is not released – but for more serious testing I think one should expect tests to take a while because they are testing a lot)
The theme of the article seems to basically be giving people what you want though: it’s a tool to take on the technical debt of order-dependent tests if one deems the trade off worth it. One could imagine a library with no such option where such tests would just fail due to ordering constraints.
Most people are not conscious of the effects of friction on their decision process unless you needle them mercilessly to examine their decision process.
Having tests not be order dependent means that the tests are independent, which means if you delete test 3 then test 6 still works. Independence of tests affects your refactoring decisions. Splitting files, combining files, 2/3 conversions, 3/2 conversions, are all a metric pain in the ass if the tests are factored poorly. That means you keep limping along with other tech debt besides the tests.
I think it’s reasonable to design the interface to guide users towards not making mistakes that will come back to bite them. Maybe this name is too antagonistic but it just seems basically benign to me.
The theme of the article seems to basically be giving people what you want though: it’s a tool to take on the technical debt of order-dependent tests if one deems the trade off worth it. One could imagine a library with no such option where such tests would just fail due to ordering constraints.