[pypy-dev] Re: unittest-module

[Michael Hudson]

holger krekel <hpk at trillke.net> writes:

> [Michael Hudson Tue, Jul 01, 2003 at 02:29:00PM +0100]
>> hpk at codespeak.net writes:
>> > Log:
>> > - improved the hack to perform specific objspace tests only when
>> >   actually running the tests with the respective objspace. 
>> >   (i.e. objspace.ann* tests are skipped for StdObjSpace and
>> >    objspace.std* for AnnObjSpace)
>> 
>> I think *a* way to do this nicely is to have test.objspace() raise a
>> "TestSkip" exception when asked for a specific object space that is
>> not the one currently being tested.
>
> I agree this is a good way. Also the "shouldStop" stuff would probably
> be better implemented by a Control-Flow Exception. 

?  Not sure I follow.  The same sort of control flow exceptions the
annotation object space uses?

>> This probably means rewriting
>> more of unittest.py, though (we want four possible outcomes: pass,
>> fail, error, skip).
>
> yep, looking at the unittest.py source this probably means
> overriding even more methods. To be honest IMO we should make our
> life easier and just drag unittest.py from python-2.3, add "skips",
> remove the leading "__" from some names plus probably do some other
> cleanups/niceties.

Would this make life easier?  As much as we bitch about unittest.py,
it has been and will continue to be a "getting us from here to there"
tool -- if we'd had to write a unittest module from scratch when we
started the project, we either wouldn't have unittests for pypy or we
wouldn't have pypy.  It may be that one day we'll be able to remove
"import unittest" from the top of tool/test.py, but that won't
diminish the usefulness unittest.py has given us.

I'm also not sure we're at the stage where a wholesale fork is the
easier option -- yet.

> Doesn't seem like incredibly hard work and we may offer it back to
> cpython, later :-)

This suffers from the distutils problem: we've no way of knowing what
other people have done in the way of subclassing unittest.Foo, so even
the slightest change carries the risk of breaking other people's test
rigs.  There might be a way to provide new behaviour by default whilst
presenting old behaviour to subclassers, but not trivially (it would
have been easier if both distutils and unittest had been written with
this in mind...).

Cheers,
M.

-- 
  Darned confusing, unless you have that magic ingredient coffee, of
  which I can pay you Tuesday for a couple pounds of extra-special
  grind today.                           -- John Mitchell, 11 Jan 1999