[libvirt] RFC: Move tests into same directory as the sources
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 Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
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).
On Tue, Jan 21, 2014 at 02:09:58PM +0200, Laine Stump wrote:
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).
In those cases I'd suggest the test go alongside the driver code rather than the conf/ code, since they have driver specific data. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On 21.01.2014 12:26, 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.
I don't think that people don't write tests because they forget. In fact, I think it's this laziness and resistance that each developer has in him/her. Having said that, I'm not against structure you're proposing but I'd be cautious with promising ourselves that it will bring more tests. I think it was us, requiring tests in patch reviews which extended our test suite the most. Looking at other projects, it's 50-50: some has tests/ separated some don't. Michal
participants (3)
-
Daniel P. Berrange -
Laine Stump -
Michal Privoznik