Pex Automated Exploratory Testing for .NET
Given a hand-written parameterized unit test, Pex analyzes the code to determine relevant test inputs fully automatically. The result is a traditional unit test suite with high code coverage. In addition, Pex suggests to the programmer how to fix bugs.Pex does not lessen the need for developers to write unit tests that define and cover the intended behavior of a method, ensuring the API and functionality meet the essential use case or user story requirements. However, Pex can be used as an additional means to ensure that tests adequately cover the implementation code. This automated exploratory testing can be especially useful for identifying unintended behavior and errors within a method.
As with most generation tools, Pex works best when used with certain conventions. Keeping methods short and testable is design principle within TDD, and this principle will make Pex's generated tests more understandable as well. Pex can also be an aid in achieving this design goal, i.e., if Pex generates numerous complex tests for a method, the method might be a candidate for refactoring. Pex also works best when methods have primitives as parameters, instead of custom objects.
By default, Pex integrates with Visual Studio 2008 and MSTest, but Pex extensions can be downloaded to support NUnit, MbUnit or xUnit.Net. Pex also builds on the Extended Reflection managed profiling API to facilitate integration of monitoring applications.
Note that Pex is currently a prototype from Microsoft Research and not a supported Microsoft product. Pex should not be used as the primary means of writing unit tests, but its automated test generation can help cover edge cases efficiently.
Very sharp and clear summary of Pex. Recently I started "exploring" Pex and I fully subscribe to your analysis regarding the use of Pex.
I worked out some (academic) test cases where I tried out Pex. If you like you can read about at appdevchronicles.blogspot.com/2008/07/pex-test-....