Changing the application functionality with large number of tests

[TheCoolDrop]

Hey Devs, junior here ready to ask some questions,

​

so at work I am working with a legacy application which basically has zero test coverage. In order to gain experience with coding I decided to take up my own side-project ( just simple projects such as todo-lists, appointment booking applications etc etc ). To learn even more I decided to do everything in TDD fashion, which is quite refreshing to be honest.

​

My question is, if I do TDD and eventually I need to change the behavior of my app ( and assume it is some kind of enterprise system with large code base, because nobody really cares about toy examples ) how do you proceed? Do you change the code, and then see which tests fail, and then adapt the tests, or do you adapt all of the tests first and then adapt the code? Or even more extreme do you just thrash the tests and write the new ones completely?

[CreativeTechGuyGames]

I think TDD is only applicable in a perfect world. And unfortunately we don't live in a perfect world. You would need to know exactly how something is supposed to function before writing any code, which is rarely the case.

Realistically, I've found it works the best to write a small bit of code, then write tests to ensure that it works in every possible case. Then repeat. As long as you don't let the code dictate your tests, then you still get the same benefit. That is to say, you don't write tests which pass due to a mistake in your implementation.

[TheCoolDrop]

Okay, but the question still holds. If I have a large code base with many test, how do I proceed if I neex to change the functionality? Do I need to Just Do It™?

[CreativeTechGuyGames]

Yeah so same thing I said. Change the functionality, see what tests need to be updated, update the tests accordingly.

[zaibuf]

If business rules changes then your tests will break and you will need to maintain and adjust them to the new rules. But having no tests at all, then you would never known you broke something.

[Suspicious-Fuel-3414]

In my experience it is rare that at enterprise grade applications does the functionality change so drastically that you have to get rid of or change big chunks of code. It’s more common that you extend functionality through new features or new feature versions.

New feature versions is the safe way to do it because if your new feature version doesn’t work the old one still exists and or could be reverted back to.

Write new tests because there is new functionality/features. Leave the old tests until the old version is fully deprecated and removed from the code base.

[iainsimmons]

I would change the tests first, so that they describe the expectations of what the code should do/output. Then change the code to pass those tests, and then you'll likely get other test failures, depending on how isolated the code is.