9

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.

Improve this question
1

4 Answers 4

Reset to default
18

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.

Improve this answer
1
  • @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.
    – Steven Evers
    Jul 29, 2013 at 18:33
8

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.

Improve this answer
1
  • 2
    +1 for mentioning a specific purpose. Ugly code that works, still works... and doesn't need to be refactored just because it's ugly.
    – Steven Evers
    Jul 29, 2013 at 18:37
3

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.

Improve this answer
0

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.

Improve this answer
2
  • 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, 2013 at 17:51
  • @Buttons840 - all the more reason to keep the existing system as-is to trace through.
    – Telastyn
    Jul 29, 2013 at 17:54

Not the answer you're looking for? Browse other questions tagged or ask your own question.