#! 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 <[EMAIL PROTECTED]> Subject: Re: unittest vs py.test? X-Nntp-Posting-Host: cola2.ca.boeing.com Content-Type: text/plain; charset=us-ascii Message-ID: <[EMAIL PROTECTED]> User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 Lines: 49 Sender: [EMAIL PROTECTED] Organization: The Boeing Company References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Mime-Version: 1.0 Date: Mon, 4 Apr 2005 15:30:36 GMT Xref: news.xs4all.nl comp.lang.python:370744
[EMAIL PROTECTED] (Roy Smith) writes: > Peter Hansen <[EMAIL PROTECTED]> 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. -- [EMAIL PROTECTED] 6-6M21 BCA CompArch Design Engineering Phone: (425) 294-4718 -- http://mail.python.org/mailman/listinfo/python-list
