Martijn Faassen wrote: > Jim Fulton wrote: > [snip] >>> I would say that there are two bugs in the case you are describing: the >>> one you meant to fix and the one which is the lack of any tests for the >>> module / class / whatever. I would bet that spending your thirty >>> minutes adding minimal tests to such a module is a *higher* value >>> activity than fixing most bugs, because it makes it easier for you (or >>> someone else) to fix that bug and others in that module. >> >> Good point. > > The PyPy project actually works with many tests that are not working. > They have an infrastructure where such tests can be in the code and > explicitly disabled. > > In some cases, the bug-reporter may be able to write a test and not fix > it. Or, alternatively, the person who goes and tries to fix a bug can > write tests but doesn't have time to fix them. > > In such case it would be nice to be able to add tests that are > explicitly disabled and thus does not show up in the normal test run. > Only when turning a knob these buggy tests show up, and a bug fixer can > then easily go and try to fix them. > > One danger is that this can be used to temporarily disable tests that > *used to work*. Then again, that's not hard to do now either.
I don't know how PyPy is managing to disable the tests. The JUnit got a recent extension, it seems, that addresses this. See : http://www.artima.com/weblogs/viewpost.jsp?thread=4603 They use a "_ignored" suffix on the test methods and they appear within the test runner report. J. -- Julien Anguenot | Nuxeo R&D (Paris, France) Open Source ECM - www.nuxeo.com CPS Platform - http://www.cps-project.org Mobile: +33 (0) 6 72 57 57 66
Description: OpenPGP digital signature
_______________________________________________ Zope3-dev mailing list Zope3email@example.com Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com