Oh la la! Combining Pex test with Team Foundation Server is indeed a powerful combination, and boy is it easy as hell to setup. The end state of this type of integration is pretty straightforward, we wanted to repeatedly provision Pex tests when executing build events in TFS.
This is a pretty awesome setup because parameterized units tests can be explicitly created, then the Pex tests can provide all the good stuff on build for the test running. Furthermore, we can even have full coverage by allowing Pex to create some of the tests that we space.
The changes required are minimal since in the build events it simply requires wiring some commands. Assuming that the tests are *already* created, you can use the MSBuild Project AssemblyName property or declaratively provide the assembly wiring the following command into your build event:
This is all fine and good, but what is you want complete coverage to ensure your tests exist? Luckily, Pex provides the /erm:wizard switch to generate the parameterized unit tests, and we can call our explicit tests using the /sa switch. This looks like the following:
pex.exe /erm:wizard test.dll /sa:test.tests.dll
Viola! Getting so easy it’s going to be hard justifying not having Unit Tests!
This one took me a little bit to understand. Sometimes the Moles exception handling is so aggressive that it becomes a little tricky to understand exactly what is bubbling up.
Assume MethodX() is a member of base class ConcreteX. Requirements state that you need to have moles for MethodX() in order to support data mocking. It is important to remember for this particular requirement that base member access is achieved by allocating the mole type of ConcreteX and passing the instance in the constructor. This looks like the following:
ConcreteX x = new ConcreteX();
Now, if it isn’t done in this fashion MethodX() will not be moled, however you can still mole the entire assembly I suppose. However, doing it in the above fashion avoids using a wrapper in partial classes and a lot of rework based on class hierarchy.
Pex as covered in past posts is a pretty great white box testing tool. But let’s assume that you want to have a “factory” in the sense that test methods can be automagically built out. An example of this is you have a list of some acceptable data type, and you want harness a test case for each one, and avoid the use of haphazard data keeping in mind that Pex will only use varying values.
In this case, you must push Pex to use parameterized unit tests since you will essentially be targeting a value from a list of values. In the below, I am assuming an array of integers is being populated by the void PopulateIntArray() method. Following, the Test method is defined which has the method decoration of PexMethod which implies it is Pex parameterized unit test. In the method, we are leveraging the PexAssume.IsTrue which means the test case fails if the condition evaluates to false.
static int intArray = PopulateIntArray();
public void Test(int index)
PexAssume.IsTrue(index >= 0 && index < intArray.Length);
int x = intArray[index];
EDIT: As Peli points out in the comments, you can use the PexArguments decoration to pass in values as well.