In a nutshell, I have a solution that builds fine in the IDE, and the unit tests all run fine with the NUnit GUI (via the NUnitit VS2008 plugin). However, when I execute my TeamCity build runner, all unit tests that require file access (e.g. for running tests against specific XML files), I just get System.IO.DirectoryNotFoundExceptions.
The reason for this is clear: it’s looking for those supporting XML files loaded by various unit tests in the wrong folder.
The way my unit tests are structured looks like this:
+-- project folder
+-- unit tests folder
+-- test.xml
+-- test.cs
+-- project file.xaml
+-- project file.xaml.cs
All of my projects own their own UnitTests folder, which contains the .cs file and any XML files, XML Schemas, etc that are necessary to run the tests.
So when I write my test.cs, I have it look for “test.xml” in the code because they are in the same folder (actually, I do something like ….\unit tests\test.xml, but that’s kind of silly). As I said before, the tests run great in NUnit. But that’s because the unit tests are part of the project. When running the unit tests from TeamCity, I am executing them against the assemblies that get copied to the main app’s output folder. These unit test XML files should not be copied willy-nilly to the output folder just to make the tests pass.
Can anyone suggest a better method of organizing my unit tests in each project (which are dependencies for the main app), such that I can execute the unit tests from NUnit and from the TeamCity build runner? The only other option I can come up with is to just put the testing XML data in code, rather than loading it from a file. I would rather not do this.
Sometimes, sleeping on a question before posting it is the best thing to do. I should have known that I should just enter the relative paths of the assemblies’ own project debug folder. Problem solved.