I’ve inherited a lot of poorly designed code; the code has no tests. I am putting tests in place before I attempt a major refactor, but I have run into a problem with my unit tests.
The problem is, I will unit test a function, and then later decide that function is a liability. I will either get rid of the function, or change its purpose. Either way, the original function gone and the unit tests fail.
Should I spend a lot of time putting unit tests into a design I will change dramatically? Wont those unit tests be useless after a major redesign?
Would integration tests be more valuable? I can chose program features I know will not change and create some integration tests to ensure they, indeed, do not change. I might change all the code behind the feature, but the feature should still work, and the integration tests should still pass.
I know there are lot of questions on similar topics. I am asking specifically about the use and value of unit test vs integration tests in messy legacy code.
1
There’s an awesome book that covers what you’re doing in great depth. Working Effectively with Legacy Code describes a number of techniques for doing just what you’re doing. The table of contents is available here. It had been recommended to me for years, and I only recently picked it up.
Basically, yes you’re correct. Test for the functionality that the users (or consuming components) will depend on, ensuring you can cover edge cases as much as humanly possible. Unit tests (via TDD) will be helpful for the new code that you’ll write to replace the existing code, while the integration tests that you wrote to cover the existing code will ensure that you’re not breaking anything and are still fulfilling your contracts.
1
Don’t worry about what the test is called – focus on the fact that the purpose of the tests is to ensure that when you refactor code it still does the same thing.
So you will be writing tests to two purposes:
- To ensure that you don’t break the existing functionality when you refactor the existing code to something more manageable.
- To define and test the function of new code you add.
In theory you should only ever be doing one or other of the above – although the challenge is that you will probably need to refactor the code to facilitate addition of new features and further – if it really is legacy – to make it testable in the first place (which is why there is an emphasis on refactoring and adding features being distinct activities).
In either case you want add tests to a purpose – you’re unlikely to be refactoring the code because just because you can, you will have objectives to be achieved and the tests that you write (unit, integration, whatever) should be those needed to support the work that moves you toward that objective.
1
In this case I think regression/integration tests would be more useful. But you’d still want to create unit tests as you’re refactoring. Also, keep in mind that unit tests are for testing what a function is supposed to do, not what it currently does. So write your tests as if the code were perfect, then refactor to make the code fit the tests.
Should I spend a lot of time putting unit tests into a design I will change dramatically?
This is arguable. If you’re changing the design dramatically, I might argue for simply leaving the old code as is and writing it anew. 200kloc isn’t that much in the grand scheme of things. If you’re not modifying the old code, unit testing it is probably worthless.
If you’re modifying it in any way, unit tests will (likely) save you time and effort.
Wont those unit tests be useless after a major redesign?
Sure, but during the redesign, they’re invaluable.
2