[TIP] Best way to do setup/teardown on a per-test basis using doctest?

[Michael Foord]

Benji York wrote:
> Michael Foord wrote:
>> Whilst I'm sure what you want can be done with doctest, it seems to 
>> offer little advantage in the general case other than forcing your 
>> tests to be inside strings
>
> I really don't like doctests in docstrings, thankfully nearly all of 
> the (hundreds of) doctests in the code bases I work with are in text 
> files.  As for the advantages of doctests, I won't repeat comments 
> that are (I believe) in the archives.

Python code in text files rather than in Python files is just as much a 
drawback as having them in strings (in my opinion). But I think to 
continue this will just be reigniting the disagreement. :-)

>
>> and use lots of angle brackets!
>
> I don't understand that remark.
Because the tests have to resemble interactive sessions and require 
lines start with '>>>' or '...'. At least that was my understanding. 
('>' being an angle bracket of course...)
>
>> I realise there are those on this list that prefer doctest, but I 
>> disagree. Doctest is great for embedding executable examples into 
>> documentation, but not so well suited for large test suites. :-)
>
> Why is that?

Because you are putting a lot of code into text rather than Python files -
adding '...' and '>>>' drove me batty when I used doctest. Plus trying 
to make stuff conditional inside the tests.

unittest is very straightforward to work with, I find the asserts 
readable and I have never run into the problems of extensibility that 
others have - so I see no reason to look for something else.

At Resolver we have around 80000 lines of test code (medium sized 
project so far?) all based on unittest for functional tests and unit 
tests. We have many TestCase classes (PerformanceTest, InstallerTest, 
FunctionalTest, GUITestCase etc) and it has served us well.

We also make heavy use of customising the framework by adding our own 
assert methods - particularly within the functional test classes that 
inspect the current application instance. I can't immediately think how 
to do this using doctest and still keep it as readable. (Effectively our 
test framework has become a DSL for testing Resolver). This may just be 
that I am not so familiar with doctest though.

Anyway, I understand that people have different tastes and may prefer 
the doctest style - I'm glad there is a choice. I also understand that 
extensibility may be more of an issue when developing testing frameworks 
for different projects with differing needs. (Composability and 
plugability being things that may be difficult with unittest - but not 
things we've needed to do.)

All the best,


Michael Foord
http://www.voidspace.org.uk