CODEWITHSUNDEEP
unit-testingrefactoringlegacy-code
SaguiItay
SaguiItay

Reputation: 2215

Starting UnitTesting on a LARGE project

Can anyone recommend some best-practices on how to tackle the problem of starting to UnitTest a large existing CodeBase? The problems that I'm currently facing include:

Obviously, I understand that I should start with refactoring the code, to make it less coupled, and more testable. However, doing such refactoring is risky without UnitTests (Chicken and Egg, anyone?).

On a side note, would you recommend starting the refactoring and writing test on the Domain classes, or on tier classes (logging, utilities, etc)?

Upvotes: 24

Views: 4370

Answers (6)

trendl
trendl

Reputation: 1147

Good luck with this... Since you have little experience with writing unit tests I recommend that you first try to gain at least some experience. Otherwise, it's likely that you'll abondon TDD/unit testing and maybe introduce new bugs into the system you're trying to unit test. The best way to gain experience is to find someone experienced who can assist you.

Upvotes: 0

guerda
guerda

Reputation: 24049

You won't get this thing right on your own. There's a lot of persuasion needed. So I want to give you this thread, where lots of information and hints for good argumentation are given: How do you persuade others to write unit-tests?

Only the whole team can create such a big size of unit-tests.

Upvotes: 1

takacsot
takacsot

Reputation: 1767

There good advices in book Manage it! by Johanna Rothman.

I could also recoment the following:

  1. Use unit test on newly created source code fregment
  2. Create unit test for bugs
  3. Create unit test for the riskiest part of the application
  4. Create unit test for the most valuable part of the application.
  5. If the coupling is too high create test which are more module or integration tests but automated.

One single unit test will not help. But it is needed to start. After while there will be handfull of unit test on the most riskiest part of the application and that will help preventing bugs in those segments. When you get to this point most of the developers will realize how usefull unit tests are.

Upvotes: 5

philant
philant

Reputation: 35816

First, I second the "Working Effectively with Legacy Code" recommendation Jeffrey Frederick gave.

As you stated in the question, you cannot change your code because you currently have no unit tests available to detect regressions, and you cannot add unit tests because your codebase is not unit-testable. In this situation, you can create characterization tests : end-to-end automatic tests that would help you detecting changes in the external behavior of your software. Once those are in place, you can start to slowly modify the code.

However, putting your HUGE code base under test is an enormous effort, highly risked, and you'll probably burn out the team doing this as they will have to produce strong efforts with low reward in terms of test coverage. Putting the entire code base under test is an endless effort.

Instead, develop new capability out of the code base, so that it won't hinder you. Once the new code is fully tested, integrate it in the code base.

Also try to create unit-tests every single time you fix a problem in the code base. It will be hard the first times, but it will get easier once you'll have some unit testing environment ready to be setup.

Upvotes: 13

TheSmurf
TheSmurf

Reputation: 15568

Gross. I've had to deal with this too. The best thing to do, I think, is to lean heavily on yucky tools that you probably don't want to use (like NUnitAsp) at first, to get the existing code under tests. Then you can start refactoring, while those tools keep your codebase from falling apart from under you.

Then, as you refactor, write more logical unit tests on the new, testable pieces that you're creating and gradually retire the original tests.

Upvotes: 0

Jeffrey Fredrick
Jeffrey Fredrick

Reputation: 4503

Lack of experience in writing UnitTests/TDD

I think this is the most significant.

Standard advice is to start writing unit tests for all your new code first so that you learn how to unit test before you attempt to unit test your existing code. I think this is good advice in theory but hard to follow in practice, since most new work is modifications of existing systems.

I think you'd be well served by having access to a "player coach", someone who could work on the project with your team and teach the skills in the process of applying them.

And I think I'm legally obligated to tell you to get Michael Feather's Working Effectively with Legacy Code.

Upvotes: 7

Related Questions