location of non-test test code

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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. 

Same here.

> 
> 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
> bzrlib/tests.
> 
> 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
would have:

bzrlib.tests.transport
bzrlib.tests.transport.sftp

etc.

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
testing.

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 ;).
> 
> Rob

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.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEuQgeJdeBCYSNAAMRAsXoAJ4hxclQv2xj9OQOue56TSjt651fLACghZie
+M6wS+x1AE1llANkws88ABQ=
=ljC+
-----END PGP SIGNATURE-----