"holger krekel" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
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" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > 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 _______________________________________________ [EMAIL PROTECTED] http://codespeak.net/mailman/listinfo/pypy-dev
