[TIP] A rare philosophical thought

[Carl Trachte]

On 8/3/08, C. Titus Brown <ctb at msu.edu> wrote:
> 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?

I know I am not one of the more hard core developers in this
conversation (I am a mining professional), but . .
Right now, IronPython runs unittest fine.  I work for folks that
demand use of the dot net framework.  IronPython is as close to that
as I can get without losing the Pythony goodness we all know and love.
 Until nose (and coverage tools like figleaf) are available for
IronPython (correct me if I'm wrong, but it's a major yank to use them
with that implementation of the language now), unittest is it.
I'm was never keen on the whole OO or bust philosophy of Java and C#
myself, but IronPython is written in C#, so folks using that
implementation of Python *might* (I'm not saying Michael is) be biased
toward that approach.
The IronPython tail definitely shouldn't be wagging the CPython dog.
I guess it's possible to stick with an older version (of unittest) if
unittest were yanked from Python 2.4 today (I know this is
impossible).  The code for unittest is still in pure Python.
OK - I've talked myself into a solution:
I'm going to store a gold plated usb stick with the code for unittest
in a deep underground bunker in an undisclosed location so that I will
never be without my unittest for IronPython . . . You can try to kill
it, Dr. Brown, but I will keep it here forever . . . Bwahahahaha . . .
(scary music)
Apologies for trolling, lack of experience, exaggerated professional
pragmatism, and general insanity.
2 more cents.

>  -> >
>  -> >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.
>
>
>  _______________________________________________
>  testing-in-python mailing list
>  testing-in-python at lists.idyll.org
>  http://lists.idyll.org/listinfo/testing-in-python
>