[meta] Testing organization and plans

Considering the benefit that we've already gained from better test coverage with the recent additions to project (maintainers, custom issue priorities) and the bugs that have been caught in the 7.x-2.x branch, I'd really like to focus on continuing and expanding our test coverage.

Problem/motivation

To that end, one of the things thats made me get more involved in testing is practicing test driven development (TDD) much more rigorously. To accomplish this, I've been using a tool that watches for filesystem changes and attempts to find the correct module name or test file and run it automatically and use a popup notification on my computer (such as Growl) to respond with the test results. This has made testing much more realtime and much more practical, and I've found it helps to have some specific organization of test files to help with this.

While I don't want to hi-jack the structure of our tests, I do think some better organization would help them, while having very few if any downsides.

Proposal

Organize our tests so that they match the following guidelines:

1. Only 1 class per file, create as many files as necessary for separating test functionality
2. Only 1 test method per class
3. Separate test files into subdirectories inside the tests/ directory
   1. integration/ for tests using the simpletest browser. All of these inherit from DrupalWebTestCase
   2. unit/ for strict unit tests only using DrupalUnitTestCase
   3. spec/ for tests that use the database but do not use the browser. Will inherit from DrupalWebTestCase even though the browser is not used in order to gain access to database functions. Also, I'm up for a better name for this, but spec is the best thing I can think of.
4. Allow a top level project(_issue).test in the tests/ directory for shared code (i.e. common helpers assertions). Individual classes in unit/ spec/ integration/ subdirectories would inherit from the classes in this top level file. This file should not contain any test methods itself.
5. The group name should be the titlized version of the short name of the module whenever possible. I'd prefer this to be an absolute rule, but this allows a feature, such that detecting the module name given the filepath of a given changed file. i.e. "Project" "Project issue" or "Project Usage" etc...

Pros:Makes organizing and finding test easier, enables test driven development, should not affect performance of tests, and tests shouldn't affect performance of module, despite the number of files.

Cons:Lots of extra files, repeated boilerplate (i.e. getInfo() or setUp()), many more items listed in the testing UI

I'm looking for feedback or improvements/changes to this proposal, and would like to start implementing something like this soon (and implement it in Project Issue as well).