[TIP] Test discovery for unittest

[Olemis Lang]

On Fri, Apr 10, 2009 at 6:49 PM, Andrew Bennetts <andrew at bemusement.org> wrote:
> 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:
>
> - Test Code Duplication (it is harder to factor out common code, like
>  assertion functions, in a doctest than in regular Python code)

This is absolutely right, that's one of the reasons why I wrote
dutest. It allows to do the following things :

- Specify setUp and tearDown in a DocTestCase subclass in order to
hide initialization and cleanup from doctests, and reuse them
- It grants access to the DocTestCase (the TestCase subclass that
checks the interactive examples) instance in doctests via the (AFAICR)
__tester__ local variable. Therefore it is possible to subclass
DocTestCase and execute one of its methods directly in the doctests. I
personally use this to call (in docstrings) the warn method defined in
the instance of TestCase. The code could look like this

{{{
#!python

class WarningTC(dutest.DocTestCase):
    def warn(tc, msg, *args):
        # Code omitted

__test__ = {
        'Precondition + init + formatting':
	                """
	                >>> try:
	                ...     extglobs.oopdbc_module.MyStack(-1)
	                ... except Exception, exc:
	                ...     if exc.message != 'Invalid parameter'
	                ...          __tester__.warn("Wrong message %s", exc.message)
	                ... else:
	                ...     __tester__.fail("Test should fail but doesn't")
	
	                """,
        [...]
}

}}}

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

What I've done in these situations is to use __test__ variable, just
like in the code snippet shown above ;o)

> - Slow Tests (same reasons as for Obscure Test)
>

Same as above

> And is directly counter to these principles, also from the same text:
>
> - Verify One Condition Per Test

Each interactive example is a condition to test

> - Keep Tests Independent

Use __test__ ;o)

> - Test Concerns Separately
>

Declare setUp & tearDown and other methods in a subclass of
DocTestCase once, and write your test assertions in doctests. I'm
mostly talking here about dutest ;o) But as I already said ...
perhaps, it's a matter of flavours.

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article: