Starting UnitTesting on a LARGE project

Question

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:

• HUGE code base
• ZERO existing UnitTests
• High coupling between classes
• Complex OM (not much I can do here - it's a complex business domain)
• Lack of experience in writing UnitTests/TDD
• Database dependency
• External sources dependencies (Web services, WCF services, NetBIOS, etc)

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)?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.