This is an archive of the discontinued LLVM Phabricator instance.

[lit] Add FILTERED test result category
ClosedPublic

Authored by yln on Apr 13 2020, 9:23 PM.

Details

Summary

Track and print the number of tests that were discovered but not
executed due to filtering options:

  • --filter (regex filter)
  • --max-tests (limits number of tests)
  • sharding feature

With this change all discovered tests are accounted for: every
discovered test is included in one of the counts printed in the summary.

Diff Detail

Event Timeline

yln created this revision.Apr 13 2020, 9:23 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 13 2020, 9:23 PM
yln marked 2 inline comments as done.Apr 13 2020, 9:28 PM
yln added inline comments.
llvm/utils/lit/lit/main.py
60

Sort all discovered tests (not just the filtered ones) for consistency in test result output. There is a test which covers this.

273

Should this be 'Filtered Out' instead? I think 'Filtered' is clear in this context, but 'Filtered Out' would be "more correct".

yln added a comment.Apr 17 2020, 2:41 PM

Any comments on this?

llvm/utils/lit/tests/selecting.py
25

It's not a strong opinion, but seeing that, Testing: 2 of 5 tests already contains all the information, and Filtered Tests : 3 looks redundant :-/

yln marked 2 inline comments as done.Apr 21 2020, 3:37 PM
yln added inline comments.
llvm/utils/lit/tests/selecting.py
25

Note that with the status bar (-sv, which is the default if you do ninja check-...) the "Testing: x of y tests" header goes away when the status bar is cleared and the summary is printed. Without a status bar (e.g., in our CI runs) this header can be thousands of lines above the summary.

This line is also only printed if you filter your tests (--filter, --max-tests, sharding feature). It shouldn't "visually bother" you if you aren not filtering your tests.

In addition, it might not be very useful in the common case, but it might be *very* useful in cases where you are not aware that some filtering is going on (and your test suite passes, because you run less tests than intended).

jdenny added inline comments.Apr 22 2020, 6:49 AM
llvm/utils/lit/lit/main.py
60

Looking through the test changes in this patch, I don't see what effect the change to this line makes. Could you explain more? Or maybe the existing tests don't reveal it?

116

What's the reason for this change? You cannot have a failure for a test that isn't executed, right?

273

I'd prefer a correct term, both here and in code (filtered_tests, mark_filtered). I think "excluded" is correct.

Moreover, "Filtered" implies tests end up here due to --filter. As you point out in the summary, tests can also end up here due to --max-tests or shards. Perhaps "excluded" is generally a better term to capture all these possibilities without implying just one of them. (I suppose you can ignore this second argument if someone's planning a --exclude.)

llvm/utils/lit/tests/selecting.py
25

It seems useful to me. Thanks for working on it.

Usually a test suite should check that the useful aspect of a feature actually works. Do you think it would be worthwhile to show in at least one test what would separate the two lines when there's no status bar?

Checking in a comment somewhere to summarize the usefulness of this feature (as in your phab comment above) seems worthwhile. This would discourage others from proposing removal of the feature because their use cases happen not to reveal its usefulness.

yln marked 4 inline comments as done.Apr 28 2020, 10:36 AM
yln added inline comments.
llvm/utils/lit/lit/main.py
60

A few existing tests fail without this because we now pass in discovered_tests in to print_results.

116

That is correct. The two unexecuted result codes "skipped" and "filtered"/(what I am trying to add here) are not failures. So it doesn't matter in this line. Overall I want to replace executed_tests with discovered_tests everywhere.

For example, we have a "fast" and a "normal" CI configuration. The normal one runs a ninja target, and the fast one runs the same ninja target with a filter. I want to include the "filtered" tests in the xml output so that it becomes easier to compare the results of the two configurations.

273

Good suggestion. I am happy with "excluded".

llvm/utils/lit/tests/selecting.py
25

I will try to add a test.

yln updated this revision to Diff 260702.Apr 28 2020, 10:55 AM

Settle on "Excluded tests". Rename filtered_tests to selected_tests.

yln updated this revision to Diff 260703.Apr 28 2020, 11:00 AM

Missed a rename in previous update.

yln marked an inline comment as done.Apr 28 2020, 11:06 AM
yln added inline comments.
llvm/utils/lit/tests/selecting.py
25

Adding a test for the usefulness is difficult: we only use the dynamic progress bar (which deletes its header, i.e., test CHECK-NOT: Testing: ...) when we detect an "interactive" terminal.
The other case is where there is a lot of output between the two lines. Are you okay with omitting a dedicated test for this?

Harbormaster completed remote builds in B55001: Diff 260703.
yln added a comment.Apr 30 2020, 1:01 PM

@jdenny friendly ping

jdenny accepted this revision.Apr 30 2020, 3:27 PM
jdenny marked an inline comment as done.

LGTM. Thanks.

llvm/utils/lit/tests/selecting.py
25

You could add something representative:

# CHECK-FILTER: Testing: 2 of 5 tests
# CHECK-FILTER: PASS: sub-suite :: test-one.txt (1 of 2)
# CHECK-FILTER: PASS: top-level-suite :: test-one.txt (2 of 2)
# CHECK-FILTER: Excluded Tests : 3

A comment would help people to understand what this represents and thus why they shouldn't see the "Excluded Tests" line as unnecessary verbosity to be removed in a later patch.

This revision is now accepted and ready to land.Apr 30 2020, 3:27 PM
This revision was automatically updated to reflect the committed changes.