[pypy-dev] Re: Re: utest conversion tool question

Terry Reedy tjreedy at udel.edu
Fri Jul 2 01:28:06 CEST 2004

"holger krekel" <hpk at trillke.net> wrote in message
news:20040701175119.GU16751 at solar.trillke...

>     http://codespeak.net/svn/user/hpk/talks/std-talk.txt

and this
> We are building AssertionErrors so that they contain detailed
> information about the asertion-expressions. For this, we override
> the builtin-AssertionError but re-interpreting arbitrary exceptions
> from the catching-side of std.utest is also possible.

are enough that I can understand this
http://codespeak.net/svn/std/trunk/src/std/ , /magic, /utest

well enough to get ideas for what I need.

"Thomas Heller" <theller at python.net> wrote in message
news:fz8br3t1.fsf at python.net...
> Reminds me of what Kent Beck writes (test-driven development by example,
> Addison-Wesley, page 119):
> """
>   But there are a couple of reasons for implementing xUnit yourself,
>   even if there is a version already available:
>   * Mastery - The spirit of xUnit is simplicity.  Martin Fowler said,
>     gotten a little complicated for my taste.  Rolling your own will
>     give you a tool over which you have a feeling of mastery.
> """

Funny you should quote this.  In the process of writing my query, it dawned
on me that this is one wheel I maybe should reimplement.  The core of what
I actually need to get started  is something like

for func in implementations:
   for case in functable:
          result = func(case[0])
          assert result == case[1]
      except AssertionError:
          print "Whoops,', result, ' is not', case[1]

Thank you both for the quick and helpful push.  This utest discussion has
gotten me to see beyond trying to choose between  doctest and unittest.

Terry J. Reedy

More information about the Pypy-dev mailing list