I am looking at a small (~70kLOC including generated) C# (.NET 4.0, some Silverlight) code-base that has very low test coverage. The code itself works in that it has passed user acceptance testing, but it is brittle and in some areas not very well factored. I would like to add solid unit test coverage around the legacy code using the usual suspects (NMock, NUnit, StatLight for the Silverlight bits).

My normal approach is to start working through the project, unit testing & refactoring, until I am satisfied with the state of the code. I've done this many times in the past, and it's worked well.

However, this time I'm thinking of using a test generator (in particular Pex) to create the test framework, then manually fleshing it out.

My question is: have you used unit test generators in the past when commencing work on a legacy codebase, and if so, would you recommend them?

My fear is that the generated tests will miss the semantic nuances of the code-base, leading to the dreaded situation of having tests for the sake of the coverage metric, rather than tests which clearly express the intended behaviour in code.

  • I tried PeX once and the results were, well, lets say, not very satisfying - YMMV. Don't expect such a tool to "understand" your code and its functional requirements - it does not miss just "semantic nuances", it misses the whole semantics. Furthermore, when you start with a legacy code base, you will typically not start with unit tests first, but with system or integration tests; that is definitely nothing what PeX was created for.
    – Doc Brown
    Jan 7, 2015 at 22:32

1 Answer 1


I would suggest looking at things a little differently. Adding new unit test code to an existing application without incident might not give you the best results. If you are doing this to get familiar with the code base or you truly have time to kill and want to test out test generators then ignore my comments.

To be pragmatic, you should look through all the bug lists. Then create unit tests for each of the bugs, resulting in how it should of behaved. Ideally, you would only add new code for each bug as you reach it.

Times to add unit test code:

  • Adding new functionality
  • Re-factored code
  • Fixed a bug
  • Learning what the code does
  • Prove a bug exists

It is difficult to quantify the value of adding unit tests after the fact.

I normally don't allow myself to write answers that are against what the asker wants, but I feel this is a good lesson to pass along.

  • I'm 100% in agreement with you there - this question arose from me wondering how best to spend some down-time. My normal practice is to test & refactor in the process of either fixing bugs, or adding features. I was hoping some people might be able to share some war-stories in this area ... Jan 4, 2011 at 6:03
  • 1
    +1, Shooting for coverage after the fact is not usually productive. Having tests on fixed bugs that prevent regression is very productive. Regression of a bug can be very frustrating for everyone involved. Tests are really suited to helping you write better code. Bolting on tests usually results in substandard tests. I think the OP's fear is founded and the signal to noise ratio from the generated tests will just get in the way. The non tested code probably has some very branchy bits in it. Tools that point out the code smells are probably more useful. Maybe FXCop and similar tools.
    – kevpie
    Jan 4, 2011 at 6:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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