[TIP] Test discovery for unittest

[Andrew Bennetts]

Olemis Lang wrote:
[...]
> I personally think that doctest is the most beautiful implementation
> ever made for the following XUnit test patterns :
> 
> - Deltha Assertion
> - Scripted Test
> - Recorded Test
> - Data-Driven Test
> - Behavior Verification
> - State Verification

It also exhibits the following smells named by the very same text:

- Fragile Test (one reason being they are Eager Tests)
- Test Code Duplication (it is harder to factor out common code, like
  assertion functions, in a doctest than in regular Python code)
- Assertion Roulette
- Obscure Test (partly because of a General Fixture; probably not all
  assertions in a single doctest file require all the state that built up
  over the course of the file, but there is no way for the reader to tell
  what is relevant to a particular assertion and what isn't.)
- Slow Tests (same reasons as for Obscure Test)

And is directly counter to these principles, also from the same text:

- Verify One Condition Per Test
- Keep Tests Independent
- Test Concerns Separately

This all from a fairly quick skim.  There are probably other issues named by
that book.

I have my own detailed gripes about how doctest is a poor format for
unittest here:

  * http://bemusement.org/diary/2008/October/23/narrative-tests
  * http://bemusement.org/diary/2008/October/24/more-doctest-problems

(Originally those were andrew.puzzling.org, but I finally got my own domain
name this week.)

-Andrew.