Problem/Motivation
In #2799021: Ensure a failing PHPUnit test shows enough information via run-tests.sh we added code to allow for PHPUnit test results in simpletest/run-tests.sh reports.
Unfortunately, this results in duplicate fail/error reports in the testbot and other tools, due to extraneous processing of Junit results, among other problems: #2602248: Test result rule name cut off
Finally there is confusion about the meaning of the various result codes sent back by PHPUnit. We often conflate exceptions with runtime errors, and we use integers when we should be using constants.
Proposed resolution
We should normalize on status codes, using a set of constants that are more global in scope than those in run-tests.sh
. Accomplish this by creating a TestStatus
class which all code can use.
simpletest_run_phpunit_tests()
should be modified to not include the junit results of fails, exceptions, or system-level problems.
Remaining tasks
Follow up to add use of TestStatus
wherever we deal with test results. Namely run-tests.sh
.
Modify simpletest ui result form so it doesn't display errors as exceptions.
Modify the testbot system to adapt to changes from this issue. #2602248: Test result rule name cut off
User interface changes
API changes
Data model changes
Comment | File | Size | Author |
---|---|---|---|
#16 | interdiff.txt | 1.46 KB | Mile23 |
#16 | 2810083_16.patch | 9.77 KB | Mile23 |
#14 | interdiff.txt | 6.16 KB | Mile23 |
#14 | 2810083_14.patch | 9.75 KB | Mile23 |
#12 | interdiff.txt | 2.67 KB | Mile23 |
Comments
Comment #2
Mile23A patch.
Comment #3
Mile23Comment #5
dawehnerNice!
Comment #6
Mile23Fixing the tests.
We should probably put this in 8.2.x, or else live with the weird testbot results until 8.3.x :-) #2602248: Test result rule name cut off
The patch applies to 8.2.x, so I'm adding an 8.2.x test here.
Comment #7
Mile23Comment #8
Mile23Comment #9
MixologicSYSTEM can be any number between 3 and 127, so Im not sure this would work. You may have to fill the status map in labelForCode with all the possible system signal errors. Everywhere we see SYSTEM we'll have to make sure we never say === we'll always have to test with >= SYSTEM as it will almost never be 3. Segfaults end up being signal 11, and there is a slew of other signals that are different from OS to OS. Suffice to say if its > 2, we consider all of those signals to be abnormal aborts as if it were a segfault.
More info here: http://php.net/manual/en/pcntl.constants.php
Otherwise, the rest of this is pretty sweet polish. Me gusta. ++
Comment #10
Mile23Hah. I replicated the same mistake, just one integer higher.
OK:
Changed the name of
labelForCode()
to justlabel()
because that's better.label()
now tells you the result code forTestStatus::SYSTEM
codes, like this:error: 3
This might not be good. Please opine.Updated the test.
Added better docs, explaining that
TestStatus::SYSTEM
is a lower limit.Comment #11
MixologicI would leave the status code off of the label. Signal numbers vary from OS to OS, so its doubtful that we'd ever want logic branches based on the signal number - easier to say if ('error') than to substr for 'error' etc. It might be interesting to have that data, but something tells me that at most we'll only ever see a few signals there.
Otherwise, still LGTM.
Comment #12
Mile23OK. Took away the status code on the 'error' label and changed the tests.
Comment #13
dawehnerThis looks quite great and almost ready.
Should we also have a test for the case of exit code > 2?
Comment #14
Mile23Sometimes, when you ask for one thing, you get five more. :-)
Refactored the test a bit, in order to get rid of
@runTestsInSeparateProcesses
and to speed things up. We can't use avfsStream
here because theexec()
'd stub test doesn't share memory with the real test.Comment #15
dawehnerafaik we use a space after the casting
Note: this is not our CS
Includes change global state and given that we should run in a separate process
Nice additional test coverage
Comment #16
Mile23Thanks.
#15.3: It's not that all includes add globals, it's that
simpletest_phpunit_run_command()
declaresglobal $base_url
. As long as we clean up afterwards there's no problem. Also, if we end up adding more globals to the code touched by the test, the test will show up as risky and we might learn something.Anyway, setting
@runTestsInSeparateProcesses
because why not. :-)All issues addressed.
Comment #17
dawehnerThank you!
Comment #18
MixologicThis would be great to get in sooner than later. Would help with fixing a lot of strange wtf reporting issues with errors.
Comment #20
Mile23Testbot is back to passing now. Patch in #16 applies locally. Setting back to RTBC and starting test again.
Comment #21
elachlan CreditAttribution: elachlan commentedIt all passes and is RTBC, can we include it?
Comment #22
alexpottCommitted and pushed 30f78fc to 8.3.x and 81ef407 to 8.2.x. Thanks!
I've committed this to 8.2.x as well because this part of the test-runner which should be viewed as @internal and correct reporting of results on DrupalCI outweighs any risks to alternate test runner implementations.
Minor code style stuff fixed on commit.
Comment #25
MixologicYay!