Take the 2-minute tour ×

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.

share|improve this question
possible duplicate of What would help when refactoring a large method to ensure that I don't break anything? and What is the most effective way to add functionality to unfamiliar, structurally unsound code? Just get (more) testers and arrange a thorough professional quality assurance in the project... –  gnat Jul 29 '13 at 18:36
add comment

marked as duplicate by gnat, BЈовић, GlenH7, MichaelT, Dan Pichelman Jul 30 '13 at 17:07


4 Answers

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.

share|improve this answer
+1 for Michael Feather's book –  Murph Jul 29 '13 at 17:25
@Murph: I'm most of the way through it and it really is a fantastic book. I'm kicking myself for not getting sooner when it was first recommended to me. –  Steve Evers Jul 29 '13 at 18:33
add comment

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:

  1. To ensure that you don't break the existing functionality when you refactor the existing code to something more manageable.
  2. 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.

share|improve this answer
+1 for mentioning a specific purpose. Ugly code that works, still works... and doesn't need to be refactored just because it's ugly. –  Steve Evers Jul 29 '13 at 18:37
add comment

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.

share|improve this answer
add comment


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.

share|improve this answer
Writing anew is temping, but it's a messy system used in production. I don't know all the little oddities of the system, but those would need to be rewritten as well (although hopefully in a cleaner way.) Bottom line, I don't fully understand the system, and I can't rewrite without first fully understanding the existing system. –  Buttons840 Jul 29 '13 at 17:51
@Buttons840 - all the more reason to keep the existing system as-is to trace through. –  Telastyn Jul 29 '13 at 17:54
add comment
