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!
I think I have actually seen this error in other versions of TFS besides 2010, but most recently saw it in 2010 deployment. Post-executing build configuration when running a build for something using Web Application projects you might receive the error:
The imported project “C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets” was not found
To solve this issue, just copy the C:\Program Files\MSBuild\Microsoft\Visual Studio\v10.0\WebApplications directory from a development machine to the build machine. Sucks but it works. Seems sporadic why it happens.
It seems I am never going to be rid of finishing these automating events! One problem that we tackled today dealt with TFS target injection, where you want to call other targets at different points in the build process. An example of this is when you want to wire a target before/after something like SolutionToBuild and ConfigurationToBuild, perhaps to do a little work before the build starts. In this case, the build was chained to **another** build to do a get on a separate VC instance, and build a related solution beforehand. There was also some WIT stuff to be done too.
Fortunately, TFS Build makes this pretty easy through the use of the Before* or After* targets (which are easily grafted from Microsoft.TeamFoundation.Build.targets), most you will ever need are existing but if you need a different one you can use a CallTarget with a MSBuild task. This can get even cooler, because you can actually start to build chained dependencies through something like: