Closed (fixed)
Project:
Drupal core
Version:
7.x-dev
Component:
simpletest.module
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
9 Jul 2016 at 14:32 UTC
Updated:
14 Jun 2024 at 15:39 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
David_Rothstein commentedHere is a patch to try to fix it. This essentially is a pseudo-backport of a small part of #2170023: Use exceptions when something goes wrong in test setup. It is possible more should be backported too (at least the tests that were added there).
This also contains patches for testing purposes that throw exceptions in setUp()/tearDown() so we can see if the fix here is doing what it is supposed to.
Comment #7
David_Rothstein commentedSo based on the above this patch is basically doing what it's expected to.
Although the results compared to the Drupal 8 patch from https://www.drupal.org/node/1970534#comment-11383991 show some interesting differences that I don't immediately understand. (Maybe it has something to do with the fact that I added the exception to a web test for Drupal 7 but to a unit test for Drupal 8?)
Above Drupal 7 patch with setUp exception:
https://www.drupal.org/files/issues/2763435-2-with-setup-exception.patch
Results:
https://www.drupal.org/pift-ci-job/364173
Results on dispatcher:
https://dispatcher.drupalci.org/job/default/169140/consoleFull
Drupal 8 patch with setUp exception:
https://www.drupal.org/files/issues/2189345-setup-exception-D8_0.patch
Results:
https://www.drupal.org/pift-ci-job/363917
Results on dispatcher:
https://dispatcher.drupalci.org/job/default/169015/consoleFull
Especially interesting is that Drupal 8 is still getting the "test runner returned a non-zero error code (2)" error here.
Comment #8
David_Rothstein commentedOh, it could actually have something to do with the fact that I threw the exception before the parent::setUp() in Drupal 7 but after in Drupal 8.
May be worth trying a comparison again with a more exactly equivalent test...
Comment #9
MixologicThe unit vs web test is more likely the culprit here. With unit tests we hand off execution to phpunit, which, if there is a fatal error, we dont really have any way of recovering from that, beyond "non zero error code", whereas if it fatals inside of drupal code, we have the opportunity to catch that exception and report on the why of the failure.
Comment #12
fjgarlin commentedA very similar fix was made as part of #3397117: SQLite testing in GitlabCI - apache2(98)Address already in use but it was taken out in favor of this existing issue.
Exceptions thrown in setUp and tearDown are now caught and therefore reported properly to the CI system.
Comment #13
bramdriesenCame here from #3397117: SQLite testing in GitlabCI - apache2(98)Address already in use after a review. I think we can RTBC this one here as well! I checked both the PIFT and the GitLab CI results and all seem fine.
Also wanted to say that #2 showed the issue in a very understandable way :)
Comment #14
poker10 commentedI have reviewed the MR and it looks good to me. Compared with the #2, the
$this->tearDown();is also moved to the try-catch block, but I think this solution is better, because we probably want alsotearDown()to run without any exceptions. If there are any problems, it would be better to stop the execution with the exception, instead of "seeing what will happen" next.Tests are also green. Adding a tag. Thanks all!
Comment #16
mcdruid commentedThanks!