Thinker

Image by Clker-Free-Vector-Images↗ from Pixabay↗

When working on an old codebase, sometimes people ask you to change an existing feature to meet new requirements. Then you go to your IDE, and you code the new feature. You write the new code and write some tests for the new code. Then you run all the tests, and then you see that there is an existing, old automated (unit) test that fails because of your changes.

Now you have two options:

Option 1

You change the existing test in order to go green with your changed implementation.

This is usually not that much work. But I’ve sometimes seen that this can be a really big mistake. Maybe the existing business logic is ok, and the new requirement was defined by some newbie business analyst that did not understand the business domain very well. That failing test should be the safety net protecting you. If you change the test to just make it pass, you will maybe find yourself in big trouble later.

But maybe changing the unit test could be correct because it just verified the software’s old behaviour and this behaviour was requested to be changed.

So how can you know?

Option 2

You really need to find out if the existing test is correct or the new requirement!

Maybe your test is well-written and self-documenting, and then you are in a lucky place. My next posts will be about writing these kinds of tests.

But maybe the test is hard to read, and you are not really sure. What to do now?

Then please:

Go the extra mile: Ask business experts, fellow developers or test engineers, especially those that have been in the company for a long time and have deep knowledge of the domain. In this case, the job title is usually not unimportant but long-time experience is really relevant! Ask them to teach you to fully understand the existing implementation, the existing unit test and the new requirement.

Never just change the existing test without fully understanding the consequences!

Maybe that will cost you one or two days. But on the other hand: Nobody will be happy about bugs, bug fixing, delayed releases or production incidents. So please: Do not rush to ship a new feature. Give yourself enough time for quality.

Having good unit tests as documentation will save you much time later.

More about Testing

Any comments or suggestions? Leave an issue or a pull request!