[TIP] Best way to do setup/teardown on a per-test basis using doctest?
fuzzyman at voidspace.org.uk
Mon Jul 2 06:13:39 PDT 2007
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,
More information about the testing-in-python