Sort of a spinoff of this question. Do you keep them in the source tree? Do you keep them in source control?
I’m thinking that if your test cases refer to files, then the files are part of the behavior specification of the system, therefore they’re associated with the current version of the system, therefore they should be checked into source control. But I don’t think they should be checked out locally, because they don’t need to be, and they can potentially be quite large. So I’m leaning towards having a parallel tree, such that if a project’s code files are at $svn/Code/foo/bar/baz, the associated test data files are in $svn/TestData/foo/bar/baz, and the latter will be accessed directly from the server using some kind of common test data helper class (which maybe caches files locally?), which can just accept relative paths and figure out where to find them. Does this make sense?
I guess there’s the related question of how extensively I should be using external files for testing in the first place. I do think they’re often good for higher-level “acceptance” tests.
Why not? Tests are an integral part of any complex software system. If they can’t run without their data, then they become useless.
The idea of remotely grabbing test data as it is needed is intriguing, but then you become reliant on a connection to your Subversion server when all you need to do is run tests. I think it adds unnecessary complexity to what should be a simple thing to do; running tests should never be a bottleneck to development.
In addition to this, you might want to consider the fact that you have to now upkeep two different svn trees. This could become a nightmare when you have multiple feature branches and releases or tags.
To explicitly answer your question, we keep our test files in <project root>/tests, so that each branch has its own set of working and useful tests.