(no subject)

#! rnews 2776
Newsgroups: comp.lang.python
Path: news.xs4all.nl!newsspool.news.xs4all.nl!transit.news.xs4all.nl!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!central.cox.net!east.cox.net!filt02.cox.net!peer01.cox.net!cox.net!attga1!attga2!attws2!ip.att.net!NetNews1!xyzzy!nntp
From: Harry George <harry.g.george at boeing.com>
Subject: Re: unittest vs py.test?
X-Nntp-Posting-Host: cola2.ca.boeing.com
Content-Type: text/plain; charset=us-ascii
Message-ID: <xqxpsxawodf.fsf at cola2.ca.boeing.com>
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3
Lines: 49
Sender: hgg9140 at cola2.ca.boeing.com
Organization: The Boeing Company
References: <roy-428D85.21040831032005 at reader1.panix.com> <6I-dnbpiIZJNJNPfRVn-hA at powergate.ca> <6oQ3e.10378$db.6219 at trndny07> <Sd6dnU9B46Le38zfRVn-uA at powergate.ca> <d2rigf$sjj$1 at panix2.panix.com>
Mime-Version: 1.0
Date: Mon, 4 Apr 2005 15:30:36 GMT
Xref: news.xs4all.nl comp.lang.python:370744

roy at panix.com (Roy Smith) writes:

> Peter Hansen  <peter at engcorp.com> wrote:
> >It seems possible to me that I might have helped him
> >solely by pointing out that unittest might not be so
> >"heavy" as some people claimed.  I got the impression
> >that he might be swayed by some unfounded claims not
> >even to look further at unittest, which I felt would
> >be a bad thing.
> 
> I'm the "him" referred to above.  I've been using unittest ever since
> it was first added to the standard library (actually, now that I think
> about it, I believe I may have been using it even before then).
> 
> And yes, I think unittest brings along a certain amount of baggage.
> There is something attractive about having the same basic framework
> work in many languages (PyUnit, JUnit, C++Unit, etc), but on the other
> hand, it does add ballast.  I use it, I certainly don't hate it, but
> on the other hand, there are enough things annoying about it that it's
> worth investing the effort to explore alternatives.
> 
> From the few days I've been playing with py.test, I think I like what
> I see, but it's got other issues.  The "optimization elides assert"
> issue we've been talking about is one.
> 
> It's also neat that I can write unittest-style test classes or go the
> simplier route of just writing static test functions, but there's a
> certain amount of TIMTOWTDI (did I spell that right?) smell to that.
> 
> I'm also finding the very terse default output from unittest (basicly
> a bunch of dots followed by "all N tests passed") highly preferable to
> py.test's verbosity.
> 
> In short, I haven't made up my mind yet, but I do appreciate the input
> I've gotten.
> 
> 

I haven't used pytest, so no comparisons to offer.  But for unittest,
I've found a lot of the "baggage" can be automated.  My mkpythonproj
(http://www.seanet.com/~hgg9140/comp/index.html#L006) does that.  When
you generate a project, you get a unittest suite with a default test
ready to run, and the mechanisms needed to add more.


-- 
harry.g.george at boeing.com
6-6M21 BCA CompArch Design Engineering
Phone: (425) 294-4718