My question is about test files by which I mean non-code files on which some of my automated tests depend (*.xml, *.xls, *.jpg etc). So I’ll use sample test files not to be confused with test files meaning code files containing tests.
Most of my automated tests are issolated unit tests but I also have some integration tests in a single project (MyApp.Tests.Integration) that verify the behaviour of classes that interact with external dependencies.
My collection of sample test files are contained in another project in my solution called MyApp.Tests.TestFiles. Each file has a build action of ‘Content’ and Copy If Newer’ set in it’s properties.
When I run my tests the solution is built and the files are copied to my output directory “bin\Debug” and my integration tests refer to them there.
The problem that triggered the question was that I’d been committing my sample test files to my svn repository, which is hosted online with a limited amount of storage, alongside my code. The files were occupying an excessive amount of space in the repository. I’ve since reconstructed the repository and reduced all sample test files to a minimum size.
In most cases the sample test files are unlikely to change so while I want them available to check out from my repository with a Working Copy, there’s no real reason to have them under version control as long as I can reconstruct the MyApp.Tests.TestFiles\TestFiles directory structure to run the tests against.
That’s the scenario, I’m hoping for answers to the following points:
- Is there a better way to work with these files?
- Would it be better to keep these files somewhere outside of my solution?
- Can I keep any required files in my svn repository but not under version control?
- Would learning more about MSBuild be helpful to me?
I doubt that there will be agreement on the “best” way to organize things. I know in my SCM system I typically like to have a single folder that contains a folder for the deployable code and the test code. Let’s say I’m building Widget and I have a dll called MyLibrary. Then the folder Widget will have a folder called MyLibrary and one called MyLibrary_test. In VS I do the same thing and I keep my test project in the same solution as my deployable project. I work alone so larger teams may find other organizing styles more suitable.
I treat my test code just like the deployable source code. It is in the source code management system. SVN keeps difference files so keeping versioned copies of your test files is not that expensive. SVN even tries to keep deltas on binaries but sometimes that doesn’t work out as well as one mighthope. I don’t believe SVN is designed to keep a single latest only copy of a source file. The “delta” approach wouldn’t work so well. The first time you accidentally make a change to a test file you’re going to wish you could go back and grab the lat working version.