Pex has had two updates, one since I first used it, and one after I finished using it. Here’s the release notes for the latest build that dropped on 5/1/2009. Fresh install, and rewinding back through the project I had referenced in my first post. This time I need to build a different project that doesn’t reference my day job and also how well things work with xUnit.
The install was perfect again, no issues with that so far. Here are the
release notes, and a few steps setting up a new project. I’m just going to start a new project and start from scratch and buzz through the same examples I worked through previously. Here’s the new project setup.
Now that I’ve got a new project to work against, we can generate the Pex test project and ask Pex to get busy. First we’ll ask Pex to create a new xUnit test project. Right-clicking the Facade project exposes the context menu, we’ll choose “Create Parameterized Unit Test Stubs”, aka PUTs.
This gives us the following dialogs to set our project properties. I’ll leave the blanks blank, those exist to filter the namespace, type name, and method names you want to filter for the project under test. We want all of them, so they’ll be left blank.
A variation on this is if you open the context menu inside the class file. The filter fields are filled in for you to limit Pex’ interaction.
Here are the settings I’ve chosen, I’m going with xUnit this time around.
The “Settings…” dialog is where I tell Pex that for all unit tests created, each will have the PexTest suffix.
"Mark all test results Inconclusive by default" - This setting will add the Assert.Inconclusive() assertion at the bottom of the test method which is the default for all Visual Studio unit tests when they are generated in the IDE.
"Globally qualify all types" - This setting will prefix all fields in the test class with global qualifier.
"Use Code Patterns" - Pex utilizes many different code patterns which are beyond the scope of this document. You can find them in this document's appendix.
"Generate Stubs file for project under test" - The Stubs Framework utilized by Pex is explained by one of the authors here.
We click OK on the settings dialog. We click OK on the main dialog, and Pex shows us the dialog pictured below. We’re getting a unit test project called …\ProjectName.Tests (plural suffix); now is your only chance to move this project around. If you like to keep your unit test libraries somewhere else besides the project it’s testing move it to that place. The MSTest dialog gives us a singular suffix. So if you have both, this might help you keep them apart. Hopefully they will allow us to (re)label them in future versions of Pex.
Click OK.
If Pex can’t find your test runner, you’ll be prompted for the location.
Here are the new pieces Pex has added.
A few things to notice here. We get one Pex class for each of our classes so the test methods are segregated neatly. The point to make here is to get everything neat before you generate the test project. Also, notice the suffix, "PexTest". We can't rename the class library suffix, so I chose to rename the class files so I know by looking at the project members which classes are mine, and which ones were generated by Pex. Also, the stub file mentioned previously is generated for us.
Here’s what Reflector can show us about what was created as well, the crunchy layer looks pretty much identical to the Crunchy layer.
namespace PeanutButter.Business.Facade.Creamy
{
/// <summary>This class contains parameterized unit tests for CreamyLayerManager</summary>
[PexClass(typeof(CreamyLayerManager))]
[PexAllowedExceptionFromTypeUnderTest(typeof(InvalidOperationException))]
[PexAllowedExceptionFromTypeUnderTest(typeof(ArgumentException), AcceptExceptionSubtypes = true)]
public partial class CreamyLayerManagerPexTest
{
/// <summary>Test stub for Add(!!0)</summary>
[PexGenericArguments(typeof(int))]
[PexMethod]
public void Add<T>([PexAssumeUnderTest]CreamyLayerManager target, T entityToAdd)
{
// TODO: add assertions to method CreamyLayerManagerPexTest.Add(CreamyLayerManager, !!0)
target.Add<T>(entityToAdd);
}
/// <summary>Test stub for Remove(!!0)</summary>
[PexGenericArguments(typeof(int))]
[PexMethod]
public void Remove<T>(
[PexAssumeUnderTest]CreamyLayerManager target,
T entityToRemove
)
{
// TODO: add assertions to method CreamyLayerManagerPexTest.Remove(CreamyLayerManager, !!0)
target.Remove<T>(entityToRemove);
}
/// <summary>Test stub for Update(!!0)</summary>
[PexGenericArguments(typeof(int))]
[PexMethod]
public void Update<T>(
[PexAssumeUnderTest]CreamyLayerManager target,
T entityToUpdate
)
{
// TODO: add assertions to method CreamyLayerManagerPexTest.Update(CreamyLayerManager, !!0)
target.Update<T>(entityToUpdate);
}
}
The only Source Analysis violation are related to moving the using statements inside the namespace declaration and the adding the method arguments to the summary block. Source and Code Analysis compliance was one of the latest features added to the Pex release in use.
Notice the method decoration "[PexMethod]" This method won't be visible to the xUnit test outline since unit tests are reference by the FactAttribute. If it would have been decorated with "[Fact]" it would. Also notice Pex methods are parameterized (PUTs) tests. The xUnit methods will be generated from, and by, the PUTs.
The PexMethod(s) will be used during the Pex Exploration we will step through now. Right-clicking the test project exposes the Pex Exploration menu item which starts the exploration process.
Pex Exploration finishes and the Pex Explorer tells us we have some problems - all of my methods are throwing NotImplementedExceptions” - nice. 
I’ll stop here, fix my code and pick-up with an Exploration exercise to allow Pex to do something meaningful with my test project.
Until then.