Daniel Russel wrote: > While I think that would be nice in theory to not read inputs, I think > sticking a whole pdb in a .py would obscure the test code.
Well, that's an extreme (and hopefully rare) case. True, it would obscure the test code. One solution is to stick it in a separate Python module and import that. But sure, for PDB files it probably makes sense to read them off the disk.
> I think defining the path to imp root path in imppy and using paths > relative to that in the tests might be an improvement since we are > pretty much stuck using imppy for the time being and that would make it > so it doesn't matter what your current directory is.
That would break my use case, which is: when a bug is fixed, I add a test case for it, and run that test case both with an 'old' version of IMP, generally that in /diva1, and with the 'fixed' version, to make sure that the old version fails and the fixed version works. Such out of tree runs would obviously fail if tests were always relative to imppy.
I don't much like having inputs for tests in a 'global' directory, since that way it is difficult to keep track of which module uses which inputs, and people that work in just their own module would have to worry about things outside of their module. (e.g. sharing a foo.pdb between two modules could cause one module to break unexpectedly if the other module's owner changes foo.pdb for a change to their own testcases.) The overhead of having multiple copies of these inputs isn't great, and we can always explicitly share files by creating symlinks - that way it's obvious that if module 'foo' symlinks to foo.pdb in core's tests, foo's author will be affected by changes in core, but not vice versa.
Per-module test inputs currently live in modules/foo/test/. It would be pretty simple for me to modify unit tests to always read files from this directory regardless of their cwd. Alternatively, maybe it would be tidier to put these inputs in their own subdirectory, e.g. modules/foo/test/data/. Opinions?
Ben