[TIP] Test discovery for unittest
Andrew Bennetts
andrew at bemusement.org
Fri Apr 10 16:49:29 PDT 2009
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.
More information about the testing-in-python
mailing list