location of non-test test code
John Arbash Meinel
john at arbash-meinel.com
Sat Jul 15 16:22:06 BST 2006
-----BEGIN PGP SIGNED MESSAGE-----
Robert Collins wrote:
> So we have quite some non-test test code:
> * test protocol servers
> * lock test helpers
> * most of bzrlib/tests/__init__.py
> I'd like to make sure that all of bzrlib/tests/ is either test code, or
> the actual code required to load the test suite, but not support code.
> The reason for this is that its IMO hard to know where to look for
> support code if its sometimes near the relevant code, and sometimes in
> Separately, but related, I've long desired to split our tests out across
> the bzrlib namespace, putting them under the thing they test - i.e.
> bzrlib.transport.tests for transport generic tests,
> bzrlib.transport.sftp.tests for sftp specific tests, etc.
I would rather have a mirrored directory inside the tests dir. So we
I think grouping the tests has value. But I would like to see them split
up more. (It would make it possible/easier to run just part of the tests).
> So, heres a two part proposal.
> Part 1:
> Lets move all the non-test test code currently in bzrlib.tests to
> bzrlib.selftest. If there is a clear home for it that is outside
> bzrlib.selftest - i.e. if its os lock specific, then I would encourage
> us to put it in lock.py.
I really don't like 'bzrlib.selftest'. Maybe 'bzrlib.test_support'?
I actually put some helper stuff into the files themselves. But after
discussing with Martin, I really don't think it should go there.
It really is nicer to keep the code itself simple, and just have a
logical place to look for the associated tests. Right now it is hard to
grep through Transports to look for a specific function/variable,
because you tend to hit on the Transport.Server, which is only used in
I really think we're combining too much stuff into a single file as it
is. Especially with all the implementations mixed into the same file as
the interface, when you are trying to find a specific function, you have
to search for the name, and then page up to see if you are in the
implementation you *think* you are in.
> Part 2:
> Lets split out the test suite for better locality of reference.
> I'm much more interested in Part 1 than Part 2, so if Part 2 is
> problematic, just ignore it ;).
I would be very happy to move the test support code out of bzrlib.tests.
I find it difficult to find the right thing when you have test files
intermixed with the support files.
I'm -1 on putting them into the files that are being tested. More +-0
about putting them next to the files that are being tested.
I really like having 'this directory is where all the functional stuff
is going on'. 'this directory is a mirror of the other one, which is
where the tests happen'. And if you are looking for the support routines
for running the tests, use <this pattern>.
I haven't quite solidified what that pattern should be.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v184.108.40.206 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the bazaar