[TIP] A rare philosophical thought

[C. Titus Brown]

On Sun, Aug 03, 2008 at 04:46:16PM +0100, Michael Foord wrote:
-> 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 HATE UNITTEST.
-> >-> >
-> >-> > 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.

I... umm... they're unnecessary?  You can do the same thing without them?
I'm confused as to how they're *not* 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?

Actually, I generally don't, but I'm a huge fan of KISSing it.  And even
when I do, nose supports all of the same functionality IF and WHEN I
need it.  If I don't need it, I don't have to use it, though.

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

"People just need to work harder to teach and learn it", in other words.
In light of my experiences with other test frameworks, and as a teacher,
I think we can reduce the teaching and learning effort required.  Is
this not a good thing?

-> >-> >> UNITTEST NEEDS TO BE REPLACED.
-> >-> >
-> >-> > 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...

Yes, but I know at least several people who teach it and use it only
BECAUSE it's in the stdlib and guaranteed to be part of Python
distributions...

That is an argument for keeping it in the stdlib -- which I agree with
-- but is it an argument for limiting the stdlib to unittest?  (No :)

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

I highly recommend that you at least take a look at nose or py.test.
Collin Winter and I & others discussed this on the list a while back
when he was proposing "unittest 3.0" for py3k [0]. He came up with a
number of nice features that were orthogonal to those present in nose &
py.test, but I think he also agreed that the test discovery and
construction features were nice.  I hope you'll find the same to be
true!

To be blunt, it seems that you're speaking from a position of ignorance
with respect to existing, widely-used unittest alternatives.  Since I
don't want to push you into rejecting nose/py.test simply out of
stubborness, I'll shut up now :)

-> 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?

Yes, that's one of the main reasons (they also support "higher-concept"
functionality like test generators, but I think those could use some
refining; they don't "fit my brain" just yet).  I have a peculiar
emphasis on keeping my test code as simple as humanly possible, so the
simplicity of test functions in nose really fits my brain, so to speak.
I also very much like the extensibility and plug-in-ability of nose: for
example, nose was really fantastic for two consulting gigs where I
needed to retrofit existing hacky test frameworks with a consistent and
universal test running interface.  I try to avoid that stuff in my own
code, though.

cheers,
--titus
--
C. Titus Brown, ctb at msu.edu

[0] See

    http://lists.idyll.org/pipermail/testing-in-python/2007-March/000198.html

and associated thread.  Also

	http://oakwinter.com/code/a-new-unittest/
	
I don't know where the effort has gone since, though.