[TIP] A rare philosophical thought

Michael Foord fuzzyman at voidspace.org.uk
Sun Aug 3 08:46:16 PDT 2008

C. Titus Brown wrote:
> On Sun, Aug 03, 2008 at 03:56:55PM +0100, Michael Foord wrote:
> -> Ben Finney wrote:
> -> > "C. Titus Brown" <ctb at msu.edu> writes:
> -> >
> -> > I love the fact that it exists and works as advertised.
> -> 
> -> I like it. The oft-cited 'boilerplate' is usually an import and a class 
> -> definition...
> You are both experienced Python developers.  Greg Wilson and I both face
> convincing people new to Python, new to programming, and new to testing
> how to use unittest.  In that sense, the boilerplace is an obstacle.
> Given that the boilerplate is in fact *boilerplate*, as both py.test and
> nose show, I am unclear as to why there is active *support* for keeping
> it.  Are you just being conservative ("hey! it works! why change it?"),
> or do you really think it serves a purpose?

That boilerplate is two lines! (Three if you count the method 
definition.) In no other context would an import and a class definition 
be counted boilerplate.

Yes I think it serves a purpose - it is the mechanism via which you 
build your test framework through providing custom testcases. Do you not 
build custom testing environments and import from them?

> -> 
> -> I'm aware of no justification for that statement...
> What, are we Wikipedia all of a sudden?  [Source needed for morally
> relativistic judgement; please supply.]  Yeesh :)
> I think it's evil because the module, the docs and the required
> boilerplate actively discourage people new to Python from testing.  It
> certainly had that effect on me; only after I started using nose did I
> begin to understand, and, to some extent, appreciate unittest.

So its a docs and a teaching issue. I don't think replacing it is the 

> Moreover, unittest is not very Pythonic.  Boilerplate is not Pythonic.
> Unnecessary code is not Pythonic.  Over-complex basic frameworks is
> unfortunately *somewhat* Pythonic (the TCP/Web stuff, anyone?) but I
> don't think it's a good aspect of Python.
> -> >
> -> > Entirely agreed on this point. I think, though, that you'll find
> -> > little immediate consensus on what to replace it with :-)
> -> 
> -> Personally I disagree - although there are obvious improvements that can 
> -> be made.
> I see widespread adoption of other unit testing frameworks (nose and
> py.test).  Doesn't this argue that in fact there is a better way to do
> it?  Why should we settle for unittest?
> There are very few strong advocates for the current unittest, which is a
> red flag all of its own.  Or is this a misperception on my part?
I expect unittest is still the most widely used testing framework by a 
long chalk...

I really need to try nose - although it will never work with IronPython 
(because of aforementioned evil hackery), and I haven't had time for 
much other than IronPython recently. When 'the book' is finished that 
will all change.

In the meantime I am interested in improving unittest as much as 
possible - although what you see as boilerplate I see as essential 
mechanisms and are unlikely to ever go away.

As I haven't used nose (and don't have issues with unittest) I don't 
'get' why you think it is simpler. Is it because you can write plain 
functions and use plain asserts?


> --titus


More information about the testing-in-python mailing list