I’m a very TDD yourself type guy. I don’t like generated tests, which totally conflicts with the first D in TDD, Test Driven Development.
Anyway, Maarten Balliauw had a really nice short post on using Pex.
Stealing from Maarten’s post, here’s an abstract from a recent session on Pex:
“Pex is an automated white box testing tool for .NET. Pex systematically tries to cover every reachable branch in a program by monitoring execution traces, and using a constraint solver to produce new test cases with different behavior. Pex can be applied to any existing .NET assembly without any pre-existing test suite. Pex will try to find counterexamples for all assertion statements in the code. Pex can be guided by hand-written parameterized unit tests, which are API usage scenarios with assertions. The result of the analysis is a test suite which can be persisted as unit tests in source code. The generated unit tests integrate with Visual Studio Team Test as well as other test frameworks. By construction, Pex produces small unit test suites with high code and assertion coverage, and reported failures always come with a test case that reproduces the issue. At Microsoft, this technique has proven highly effective in testing even an extremely well-tested component.”
In the simple example Maarten used he showed how Pex may be a great tool to run after your TDD tests are finished just to possibly catch any edge cases you missed.
However, make sure you refactor after including any code Pex suggested. In Maarten’s post the last check ( if(length < 0)) is never entered because it is included in the check by Pex ( if (length < 0 || current.Length < length)). This entire block can be removed. It’s not harmful in anyway, but can be a little confusing and should be cleaned up. ReSharper probably would catch it.
I’m going to have to give Pex a try!