Merge lp:~yellow/subunit/test-count into lp:~subunit/subunit/trunk
| Status: | Rejected |
|---|---|
| Rejected by: | Robert Collins on 2012-05-03 |
| Proposed branch: | lp:~yellow/subunit/test-count |
| Merge into: | lp:~subunit/subunit/trunk |
| Diff against target: |
101 lines (+15/-10) 2 files modified
python/subunit/test_results.py (+12/-0) python/subunit/tests/test_subunit_filter.py (+3/-10) |
| To merge this branch: | bzr merge lp:~yellow/subunit/test-count |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Jonathan Lange | 2012-04-26 | Disapprove on 2012-04-26 | |
|
Review via email:
|
|||
Description of the Change
This branch changes the semantics of testsRun in a TestResultFilter to count the total number of tests run, not the number of tests filtered.
Whether these semantics are correct is up for debate. We're obviously proposing that they are. That said, these changes primarily exist to make the testrepository change in lp:~yellow/testrepository/bug988481 cleaner. We don't know how to continue to subclass in testrepository.
This is work done by Benji York and Brad Crittenden; I'm just helping out with the MP.
| Jonathan Lange (jml) wrote : | # |
Hey guys,
Thanks for looking into this one. I don't think that this change should go into subunit. The _get_concrete_
What testrepository needs is a way to increment testsRun on its CLITestResult instance even when tests are filtered out of the stream. The right way to do this is to pass that result into TestResultFilter somehow. Here are some options:
class MyTestResultFil
def __init__(self, result, on_filter, **kwargs):
super(
self.
def _filtered(self):
super(
self.
Or you could make the last line:
self.
Instead of writing that as a subclass, it could be a patch to TestResultFilter in subunit. In which case it would have to be an optional argument. Then you could call TestResultFilte
Alternatively, you could make a more specific version and have it live in testrepository:
class MyTestResultFil
def __init__(self, result, cli_test_result, **kwargs):
super(
self.
def _filtered(self):
super(
self.
I'm sorry to bounce back so hard on this, but the getattr() searching is really quite fragile.
Thanks,
jml
| Gary Poster (gary) wrote : | # |
Hi Jono.
While this change is stand-alone from subunit's perspective, we actually were working with https:/
Without the filter-tags branch, http://
However, with the filter-tags branch and the testrepository patch above, we still need to address additional failures: http://
The _PredicateFilter refactoring in the filter-tags branch makes it harder to come up with a solution. The _filtered override changes you suggested will break just as much as the existing _filtered method override does. If instead we override addFailure, addError, and addSkip to increment testsRun there, we double count tests that matched the filter.
I think the best approach will be a subunit change like the one you gave...except that I think the argument will need to be something on the order of "on_filter," because we need to increment testsRun manually only when a test is filtered out in order to get the behavior testrepository desires. I'll make a new branch that does that.
Thanks,
Gary
| Robert Collins (lifeless) wrote : | # |
So, I'm going to disagree with this patch from another angle: its
inappropriate coupling.
TestRepository can just use a Y join to get a separate count vs
filtered tests. (And BTW, the *filtered* count there is appropriate
for UI consumption, so I don't see how this would help with it
anyway).
| Jonathan Lange (jml) wrote : | # |
The filtered count (i.e. the number of tests that we display in the output) might be appropriate for UI consumption (e.g. 7 failing tests), but the UI also needs to have the unfiltered count (e.g. 100 tests run).
The UI layer can use a Y join, I guess. I can't fully connect the dots in my head but I can see how it might work.
| Robert Collins (lifeless) wrote : | # |
To join the dots, see my whiteboard image on the list.
Unmerged revisions
- 164. By Benji York on 2012-04-26
-
make filtered test results report the total number of tests

I'm not 100% sure about this change, but I can't think of any actual use case for which this would be a regression.