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)) |
