[pypy-dev] Maybe Ian Bicking wants our test framework.

[Nicolas Chauvat]

> For one, we have interpreter-level and app-level tests, further 
> parametrized by Object Spaces. Also we are using tools (such as 
> dot, clisp, ...) which may sometimes not be there and there is 
> no clean way to skip those tests.  And i'd like to have a 
> "TestConsole" that allows me to repetively rerun failing tests 
> until the implementation is fixed, IOW support test-driven development
> directly.  Plus i'd like pluggable report modules (producing
> html for automated tests on the web-page etc.) and, and and. 
> 
> unittest.py and most of the above mentioned replacements don't
> seem to be designed for all these uses. I think it makes sense
> to tackle a rewrite of unit-test making all those use-cases
> easy and pythonic maybe not only for PyPy.  I am not sure how 
> much of the current std/unittest.py API/internals we want to 
> inherit, though. 

We happen to have written our own encapsulation to unittest in order
to get our automated testing framework up and running at Logilab.
I'd be interested in such a rewrite and/or addition to std/unittest
which is already pretty good as it is.

-- 
Nicolas Chauvat

http://www.logilab.com - "Mais où est donc Ornicar ?" - LOGILAB, Paris (France)