Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

All Errors not reported as Failure #6

Open
AFBarstow opened this issue Mar 29, 2015 · 8 comments
Open

All Errors not reported as Failure #6

AFBarstow opened this issue Mar 29, 2015 · 8 comments
Assignees
Labels

Comments

@AFBarstow
Copy link

The all test results file [1] has results for 5 UAs and it includes about 40 test files that resulted in 4 Failures plus 1 Timeout. My expectation is that test failures like these are included in the less-than-two table and/or or the complete-fails table yet that didn't happen (see [2] and [3]). That seems like a bug to me.

/cc @bzbarsky @plehegar @siusin

[1] http://w3c.github.io/test-results/websockets/all.html
[2] http://w3c.github.io/test-results/websockets/less-than-2.html
[3] http://w3c.github.io/test-results/websockets/complete-fails.html

@darobin
Copy link
Member

darobin commented Mar 30, 2015

Are you talking about the lines that state "ERROR"? These aren't test failures, they're a problem with the test. The problem isn't that they should be reported, it's that they should be fixed so that they don't error when running. Reporting them as failures makes no more (but no less) sense than reporting them as passes: they are bugs and as data points they are meaningless.

@siusin
Copy link

siusin commented Mar 30, 2015

@darobin
I agree that "errors" should not be considered as failures. Is it possible to produce another file for the "errors" besides the "less-than-2" or "complete-fails"? I can submit a PR to wptreport if you think it helps.

@darobin
Copy link
Member

darobin commented Mar 30, 2015

Yes, I think that would be useful. Also, maybe you could have wptreport list errors on the console when it runs? That might lead people to pay more attention to them.

@siusin
Copy link

siusin commented Mar 30, 2015

SGTM :)

@bzbarsky
Copy link

These aren't test failures, they're a problem with the test.

But for purposes of determining interop these mean at best that we have less test coverage than we think. It seems to me that progressing to REC should require not having such things in the test suite...

@darobin
Copy link
Member

darobin commented Mar 30, 2015

I completely agree @bzbarsky, they shouldn't be glossed over. Reporting them as test failures is not the right option, but they need be reported.

@AFBarstow
Copy link
Author

@siusin yes, putting failures^H^H^H^H^H^H^H^Herrors like the ones I reported in a separate file would be fine. Thanks!

@halindrome
Copy link
Contributor

I don't think this ever happened. Prioritizing.

@halindrome halindrome added the bug label Sep 15, 2016
@halindrome halindrome self-assigned this Sep 15, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants