On 01/21/2014 01:26 PM, Daniel P. Berrange wrote: > Currently we have a split with all the "source" code under various > subdirectories of src/, while the test cases are (mostly) all under > the tests/ directory. I think there could be some benefits to moving > the test files to be alongside the source files being tested. > eg instead of tests/virhashtest.c have src/util/virhashtest.c > > The tests/ directory is getting reasonably large, and is likely to > grow even more as we push for greater unit tests. We could split it > up into various sub-directories mirroring the split of dirs under > src/, but it seems easier to put have them directory under src/ and > remove the arbitrary split of source and tests. > > Having the test files alongside the source files makes it obvious > to anyone looking in a directory that tests exist for a file. This > might encourage people to think about adding tests when changing > a source file. It also makes it more slightly obvious which files > lack proper tests. > > In essence I'm suggesting that our code file naming should be thus > > virfoo.h - exports of module foo for general internal usage > virfoo.c - implementation of module foo > virfoopriv.h - exports of module foo for test suite usage only > virfootest.c - implementation of tests for module foo > virfoomock.c - implementation of LD_PRELOAD hack for module foo tests Having things organized both in smaller chunks and with the test more closely related to the source does seem like a good idea. If there will be multiple test source files in a directory, perhaps we could have a "test" subdirectory for each source directory? And then of course there are the tests that exercise some lower level function at a higher level (e.g. the xml2argv tests, which are exercising stuff in both /conf and /qemu etc).