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 was at a client today, working on a TFS 2008 cube corruption problem (I hate the super common code churn crap it always throws, requiring weird InstanceInfo and SetupWarehouse voodoo) when the subject of automating BizTalk 2009 projects came up.
The company heavily uses BizTalk, so they threw up a staging server with BizTalk 2009 on it and ran the Team Foundation Server Build Setup. After this, building non-BizTalk projects was working just fine, but BizTalk projects fail to build. After examining the box, they had copied various things from a BizTalk development workstation, but none of the additions had any effect. The rationale behind this was they don’t want Visual Studio on the staging server, but without it when running the BizTalk install the Developer Tools and SDK option is not selectable.
To get around this, look during the installation of BizTalk under Additional Software, and find the Project Build Component feature. While this allows for builds without Visual Studio, it should be noted that you can’t generate MSI packages, just build stuff.
It’s my last day of my TFS migration, which I will admit I am pretty happy about being complete with. Everything goes into testing for the next couple weeks, so it’s time to sit back and see what people can break.
An interesting point came up today on the second to last project we were converting for build automation. One of the solutions composed of multiple projects employs a separate third party pickup program for deployment of its respective packages, and because of its nature this scheme is not mutable. Off the cuff, this is obviously a no brainer to configure the build drops, but the requirement became slightly more complex. This particular program required a junction point drop, so when a solution structured with multiple projects is assembled it would output project contents under $(BinariesRoot)\project ($(BinariesRoot) being where TFS Build wants to place your binaries during a build, TFS Build sets $(OutDir) to $(BinariesRoot)), as opposed to restricted to the default solution structure. This could be for any number of projects within the solution, $(BinariesRoot)\projectX, $(BinariesRoot)\projectY, $(BinariesRoot)\projectZ, etc.
The solution to this is to use $(CustomizableOutDir) (false by default!) which will use the project settings instead of being overridden by TFS Build. So in each .csproj file you would have: