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.
Best Answer
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:
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.