[TIP] Unittest Changes

[Andrew Bennetts]

Christoph Zwerschke wrote:
> Jonathan Lange schrieb:
>  > The aim is to incorporate improvements to unittest that have stood the
>  > test of time in real projects, rather than to come up with blue-sky
>  > features.
> 
> I think the new features of JUnit4 should also be taken into 
> consideration (see e.g. http://www.devx.com/Java/Article/31983)
> for a remake of pyUnit. For instance, I sometimes missed setup and 
> teardown methods that are executed only once per Test class.

I agree with Jonathan here.  Twisted's setUpClass/tearDownClass were terrible,
for the reasons he gave.

Also, TestCase subclasses have multiple possible uses:

  - to group and organise tests, so that you can selectively run particular
    subsets easily (good test runners let you name tests to run by test case
    name or even by a regex).
  - to group/organise tests for clarity, e.g. so that you can keep similar tests
    with different intent separate, such as white-box and black-box tests of a
    class.
  - to share common fixture set up/tear down.
  - to share common assertions and other test helpers.
  - to parameterise tests (i.e. run the same tests multiple times against
    different scenarios).
  - just because the author thought they needed one to write some test methods
    (unaware of alternatives like FunctionTestCase).

That's really too many things, and it leads to confused and confusing code.
Very few TestCases I've seen make it explicit which of the above are the
reason(s) the TestCase subclass, which means people add to them and subclass
them more or less at random.

To add sharing of common fixture instances to that list would make it even
harder for a reader of test code to guess why a TestCase was made.

I suggest keeping infrastructure for sharing fixtures separate to TestCase.  The
testresources module Jonathan points at is one such option.

-Andrew.