Discoveries regarding the relationship between CUIT and the Build Process

29 March 2012 | Daniel Falk | Uncategorized

While performing the experiments described in this post, I made some interesting discoveries about the relationship between Automated Testing with CUIT and the Build Process.  Here are my findings thus far.

Discovered that a Build must be associated to the Test Plan (either through the properties or via the Run With Options selection) in order to run Automated Tests via MTM.  Even if the Test Settings have all diagnostics deselected.  Poked around on Google a bit and people seem to all agree that you have to do it, but I have yet to see an explanation for why.

I’ve posted about this on the MSDN boards.  This was the answer I received, which seems to make sense.

I’ve tried another experiment where I made a simple WinForms form app, added that Solution to Source Control, created a Build that only handles that WinForm form app (note: does not include Test Solution), and then associated the Test Plan with that Build instead.  When I tried to execute the test, I received the following error: “Build directory of the test run is not specified or does not exist.”  NOTE: I also left the Drop Location blank by unflagging under Build Defaults and also under Process -> Advanced.

I’ve made a third Build Definition that includes both the simple DX form app and the Test Solution.  Same results as above.  In this Build Definition, I left the Drop Location blank as before.

I’ve modified the third Build Definition such that it now has a Drop Location.  The Build succeeded and the tests also succeeded.

I modified the second Build Definition that contained only the sln file for the simple WinForms app I made.  The build succeeded.  Then I switched the build in MTM to this build and tried to execute the tests.  The test run failed and threw the following error: “File does not exist.  Could not find file <dll for test project inside the drop location>”.  Evidently a tester needs the CUIT files to be included in the build against which it is testing.  This follows from the MSDN post referenced above.

Leave a Reply