Hi Guys, I'm trying to understand what's the best way to manage older unit test that doesn't really match or works anymore due to reason like bugs or logic changes in your code? Do we just skip them all by and modify them to fit the current logic?
For example if those tests weren't written by you, and now you're in charge to modify the code. Do you still take the time to update those test to make it pass before moving on?
Or just skip them? Thanks.
Unit tests that are out-of-date are useless. If you want them to be of use, update them.
Of course you should take time to make them pass. Why throw that work away?
The whole idea of TDD is to have all the tests pass all the time. From the moment you start saying, "hey, it's okay that this unit test fails", TDD is useless. It requires some discipline, yes, but it's worth it in the end.
For example if those tests weren't written by you, and now you're in charge to modify the code. Do you still take the time to update those test to make it pass before moving on?
I would update the tests.
But first I would hunt down the developer who broke them and... well here's some inspiration.
Each time I am in a similar situation, there is such a hurry that I consider the obsolete tests non-existent. As a consequence I consider the code as legacy code and I write new tests only for the feature I work on.
There are two possible situations there:
It is never acceptable to have a failing test. You systems should reject any chances that do not have every test pass, or at a minimum a failing test should trigger a priority work task to the developer that caused the test to fail.
Over time tests do become obsolete particularly with mature products. At best they serve to simply exercise the code. Sometimes they'll fail but usually for reasons not associated with why they were written in the first place. You have to use your judgment as to whether to discard an obsolete test or not. We have 10,000s of tests if we didn't occasionally chop out the dead wood the tests would take too long to complete.
Test coverage tools can help you determine whether any particular test is worth keeping or not.
When a test fails, there are three options:
Before writing any new code, all tests must pass. When tests fail, you must fix them immediately, or revert your changes. Otherwise you can not be sure that when the tests fail, whether it was because of the change that you made one minute ago, or whether it is just a false alarm.
Ignoring failing tests is a path to the dark side. If you ignore them long enough, the test suit will rot as even more tests fail, and it will lose its value and you need to throw the tests away. And then when you can not anymore rely on the test suite, you will hesitate to improve the design of the production code, and also the production code will begin to rot. Finally it's not anymore possible to maintain the production code, and you will need to throw also it away and rewrite it.