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

[Terry Reedy]

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

This
>     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:
      try:
          result = func(case[0])
          assert result == case[1]
      except AssertionError:
          print "Whoops,', result, ' is not', case[1]
          print
==============================================

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