Merge lp:~jml/testtools/forward-current-tags into lp:~testtools-committers/testtools/trunk
Status: | Merged |
---|---|
Merged at revision: | 248 |
Proposed branch: | lp:~jml/testtools/forward-current-tags |
Merge into: | lp:~testtools-committers/testtools/trunk |
Diff against target: |
487 lines (+259/-27) 6 files modified
testtools/tags.py (+34/-0) testtools/testresult/doubles.py (+21/-6) testtools/testresult/real.py (+43/-14) testtools/tests/__init__.py (+2/-0) testtools/tests/test_tags.py (+84/-0) testtools/tests/test_testresult.py (+75/-7) |
To merge this branch: | bzr merge lp:~jml/testtools/forward-current-tags |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
testtools committers | Pending | ||
Review via email: mp+101538@code.launchpad.net |
Commit message
Revamp testtools's tag support to correctly conform to the subunit standard and to have a rigorous test suite.
Description of the change
I tried to write a subunit tag filter and could not due to bugs in the way that tags behave in testtools. At around the same time, we received reports from the Launchpad developers that testtools TestResult and friends assume that tags are one continuous stream, and does not scope them for tests as described in the subunit README.
To address both of these issues, I wrote a bunch of tests that exercise the "tags" contract of TestResults. I've updated TestResult, MultiTestResult, ExtendedToOrigi
While doing this I discovered that testtools was under the impression that Python 2.7 has tags support. It does not, and I removed the tests that suggested otherwise: it's a bug if code calls a Python 2.6 or 2.7 TestResult expecting tags to work.
To implement this better I made a TagContext object. I originally implemented this with functions alone (you can see the implementation at r253), but switched to a class as it seemed to be more readable to me.