Problem/Motivation
When assertWaitOnAjaxRequest() fails, it uses \RuntimeException which immediately halts the test and bypasses things like tearDown().
Discovered at #3218985-20: CKEditor 5 admin UI's AJAX logic and form alterations are too complex and brittle and #3218985-21: CKEditor 5 admin UI's AJAX logic and form alterations are too complex and brittle:
What's weird is that
\Drupal\Tests\ckeditor5\FunctionalJavascript\CKEditor5TestBase::tearDown()which was added in #3228355: PHP warning when saving text format with CKE5: $form_state->getTriggeringElement() unexpectedly returning NULL should be causing this to be visible, but it's … just not. It seems that thetearDown()is perhaps not being called in the case of Functional JS tests failing early? Yet::tearDown()is supposed to be called always… I could decorate$assert_session->assertWaitOnAjaxRequest();in CKE5 tests just so we get better error response checking… using the same technique as I added in\Drupal\Tests\media\FunctionalJavascript\CKEditorIntegrationTest::getLastPreviewRequestTransferSize().
+
Actually … I think I figured out why:
00:06:37.487 FATAL Drupal\Tests\ckeditor5\FunctionalJavascript\CKEditor5Test: test runner returned a non-zero error code (2).This is because
\Drupal\FunctionalJavascriptTests\JSWebAssert::assertWaitOnAjaxRequest()triggers a\RuntimeExceptionthat the test runner won't handle. So it instantly aborts the test, without running::tearDown()!
While the plan is to remove assertWaitOnAjaxRequest, in the meantime this fix will stop preventing issues like #3228956: PHP notices are not detected for headless browser-triggered requests in FunctionalJavascript tests from progressing.
Steps to reproduce
TBD
Proposed resolution
Replace \RuntimeException with Behat\Mink\Exception\ExpectationException
Remaining tasks
Write tests
User interface changes
N/A
API changes
N/A
Data model changes
N/A
Release notes snippet
N/A
| Comment | File | Size | Author |
|---|
Issue fork drupal-3230726
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #3
larowlanMakes sense
Comment #4
longwaveNW for MR feedback.
Comment #5
tim.plunkettI mentioned needing tests in the IS, forgot to tag.
Addressed MR feedback.
Comment #6
tim.plunkettAttaching a failing patch to go along with the MR which should pass.
Comment #8
tim.plunkettPatch failed as expected, branch is passing.
Comment #9
longwaveLooks good to me, test coverage makes sense.
Comment #10
xjmNW for small fixes above.
Comment #11
wim leers