This set of takeaways seems quite solid to me.
In particular, I've pushed the "remove tests that haven't failed in years" before, but never had any traction. Are there teams that actually do this?
In particular, I've pushed the "remove tests that haven't failed in years" before, but never had any traction. Are there teams that actually do this?
So, in short, no. It is not just a time bound thing. However, if you have not had a test fail in years, it is a good time to audit the test to make sure it is still relevant. If it isn't, get rid of it.
It is this kind of logic that insists on the pre flight video that everyone ignores. We can, and should, do better.
The article mentions testing X=5. Is not worth while testing.
It depends on your unit. If the unit is calculator class, then testing this simple function is may be worth testing. If the class is highly level biz rule it may not add any value. If this test is testing an parser parsing X=5 as example for X=<value> sure. You must test this trivial case as well.
Think about unittests as logs of debug sessions for this particular class that you would produce to prove a certain point about your code.
Keep them simple. Easy to understand. If they fail the failure should explain the failure. You need to much time analysing the failure of your unittest. Redesign them and/or your code to explain failure better.
I think the author has probably seen spaghetti unittests to many times - I.e. unittests that don't follow a purpose - just trying to hit code coverage without the intention to prove a rule about the code.
also, the advise adjusting code for unittest destroys your architecture is completely wrong. The better your code supports your tests the better the architecture will be. it will be more flexible and has already two use case. The real biz case and the case of unittest. This makes your architecture more robust against change.
I do think adjusting your code for the unit tests can destroy the architecture. However, I don't think this is necessarily bad. Consider all of the "dual purposes" that pretty much every single piece of a rocket serve. The catch, is most of us are not building a rocket; so a forcing function for single responsibility is mostly a good thing.
Instead, lean on the judgement of the people working the system. If it hasn't failed in years, it should be audited to see if it can fail. And if not, removed/revised. Obviously at the discretion of the entire team. (This would be a code reviewed change, after all.)