Donnerstag, 13. Juli 2017

TFS 2015 - setting the test run working directory of a Visual Studio Test task

We're moving from ccnet to TFS 2015. So it's the TFS 2015 build system, doing integration and nightly full builds.
Of course there's also tests, which are run by vstest.console.exe via a Visual Studio Test Task.
Unfortunately, many of our tests use resources which are parked outside of the test lib, in some "TestDataFolder". This works all great as long as your current working directory is what you think it is. (side note: I strongly disagree with this. Imho, all test resources should be included in the test lib. If you need too many resources, you're likely doing something wrong.).

Note: It looks like I experienced this only for test assemblies that had used [DeploymentItem(..)] attribute. Without such an attribute, the test dir seems to be the directory where the library is build to.

Anyhow. These builds are run by TFS agents. And those have a working directory, like:
E:\agentX\_work\13\
13 being .. the 13th checked out source branch? Don't know yet.

The sources are in
E:\agentX\_work\13\s\

And the test lib in e.g. E:\agentX\_work\13\s\MySolution\MegaLib.Tests\bin\MegaLib.Tests.dll is executed with vstest.console.exe from the path:
E:\agentX\_work\13\TestResults\<deploy_id_date>\out

That sucks, cause being outside of the source tree, the logic for finding the "TestDataFolder" doesn't work anymore.
It took a while to find out how to set the base directory of each test run.

Solution: use a myTestSettings.runsettings file, and set the ResultsDirectory for the TestResults, which also manipulates the current working directory when the tests are run.
<RunSettings>  
 <RunConfiguration>
  <!-- Path relative to solution directory.
                        It also makes the directory traversal
                        for finding the unittestdata folder work -->  
  <ResultsDirectory>.\TestResults</ResultsDirectory>
 </RunConfiguration>  
</RunSettings>  
The path for myTestSettings.runsettings is relative to the source root directory (for which even a variable exists: $(Build.SourcesDirectory))
Well, there's probably also a way to set the Common.TestResultsDirectory, but I haven't found out yet how to do that via such a VSTest task (from TFS build - predefined variables).

Freitag, 9. Juni 2017

Using shareProcess instead of ownProcess for windows services can yield a very confusing message

When registering a windows service with an msi, using wix, one is usually doing this:
<wix:ServiceInstall Id="MyServiceInstall"
     Name="MyService (Hostfunc1)"
     DisplayName="My Super Service"
     Description="Some Description"
     ErrorControl="ignore" 
     Start="auto"
     Type="ownProcess" 
     Vital="yes" 
     Interactive="no" 
     Account="[SERVICEUSER]"
     Password="[SERVICEPWD]" />

I did the mistake of using
Type="shareProcess"
which gave me the perfectly correct error message that didn't help me at all:
"Error 1083: The executable program that this service is configured to run in does not implement the service."

Setting the Type to "ownProcess" again solved the problem.