Closed
Bug 1225781
Opened 10 years ago
Closed 9 years ago
./mach xpcshell-test no longer exits with code 1 if a test fails
Categories
(Testing :: XPCShell Harness, defect)
Testing
XPCShell Harness
Tracking
(firefox52 fixed)
RESOLVED
FIXED
mozilla52
| Tracking | Status | |
|---|---|---|
| firefox52 | --- | fixed |
People
(Reporter: standard8, Assigned: glasserc)
References
Details
(Keywords: regression)
Attachments
(1 file)
I just noticed that forcing a xpcshell-test to fail and doing something like:
./mach xpcshell-test browser/components/loop/test/xpcshell/test_loopservice_initialize.js; echo $?
shows '0' rather than '1'.
We were using this in one of our helper scripts on Hello, to ensure that the script stopped when tests failed.
I tracked the regression range to bug 1193257.
| Reporter | ||
Comment 1•10 years ago
|
||
So something did change, but the fix may be more complicated. On re-reading the code before bug 1193257 landed, it looks like:
- `./mach xpcshell` would always return 0, even if there was failure (presumably due to making the test servers happy)
- `./mach xpcshell <test path>` would return 1 on failure, 0 on pass.
This probably needs someone slightly more familiar with the code to look at it ;-)
Assignee: standard8 → nobody
| Assignee | ||
Updated•9 years ago
|
Assignee: nobody → eglassercamp
| Comment hidden (mozreview-request) |
| Assignee | ||
Comment 3•9 years ago
|
||
I also discovered this behavior by accident. I'm not 100% sure I understand :standard8's comment #1 (why would the test servers need the xpcshell command to return 0 if there are failures?) but it was easy enough to add code that only returns the exit status if paths were passed to it. I tagged :ahal as a reviewer because he reviewed the bug that introduced the regression, feel free to change that if it's wrong!
Comment 4•9 years ago
|
||
| mozreview-review | ||
Comment on attachment 8798209 [details]
Bug 1225781: Return exit status of tests,
https://reviewboard.mozilla.org/r/83730/#review82454
::: testing/xpcshell/mach_commands.py:390
(Diff revision 1)
> - return xpcshell.run_test(**params)
> + status = xpcshell.run_test(**params)
> except InvalidTestPathError as e:
> print(e.message)
> return 1
> +
> + if params.get("testPaths"):
> + return status
We should always return the status. I think the only problem was that run_test wasn't returning self.run_suite, which means it returns None which python then converts to 0.
So remove this change and I think the patch would be good. Though would still be a good idea to verify the original problem is fixed.
Attachment #8798209 -
Flags: review?(ahalberstadt) → review+
| Comment hidden (mozreview-request) |
| Assignee | ||
Comment 6•9 years ago
|
||
| mozreview-review-reply | ||
Comment on attachment 8798209 [details]
Bug 1225781: Return exit status of tests,
https://reviewboard.mozilla.org/r/83730/#review82454
> We should always return the status. I think the only problem was that run_test wasn't returning self.run_suite, which means it returns None which python then converts to 0.
>
> So remove this change and I think the patch would be good. Though would still be a good idea to verify the original problem is fixed.
Is there a test suite or something that I could add a unit test to? I verified that the change worked by adding a failure to an xpcshell test using `equal(1, 2)` and then running it with `./mach xpcshell-test path/to/failing/test.js; echo $?`.
Comment 7•9 years ago
|
||
We have tests for the xpcshell harness, but not for any of the mach commands, sadly.
Comment 8•9 years ago
|
||
And there is actually a test for this in selftest.py already:
https://dxr.mozilla.org/mozilla-central/source/testing/xpcshell/selftest.py#837
So at least we can be confident it's working in automation I guess :/
| Assignee | ||
Updated•9 years ago
|
Keywords: checkin-needed
Pushed by mbanner@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/0f0f7bba7277
Return exit status of tests, r=ahal
Keywords: checkin-needed
Comment 10•9 years ago
|
||
| bugherder | ||
Status: NEW → RESOLVED
Closed: 9 years ago
status-firefox52:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla52
You need to log in
before you can comment on or make changes to this bug.
Description
•