Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question

1 Answer 1

up vote 7 down vote accepted

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.

share|improve this answer
    
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 ... –  Duncan Bayne Jan 4 '11 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 '11 at 6:17

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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