Problem/Motivation

One nice feature of WebTestBase is that for each error we have, we automatically trigger an error in the test

Proposed resolution

Let's add this to BrowserTestBase itself.

Remaining tasks

User interface changes

API changes

Data model changes

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

dawehner created an issue. See original summary.

dawehner’s picture

Status: Active » Needs review
FileSize
4.15 KB

Status: Needs review » Needs work

The last submitted patch, 2: 2664150-2.patch, failed testing.

larowlan’s picture

Yeah spent some time on this on Friday on a client test, will ping you for a chat with some ideas

larowlan’s picture

+ if ($driver)
 return $session;

You have an extra if that I think is preventing the session return

dawehner’s picture

Status: Needs work » Needs review
FileSize
4.13 KB

Ha, well, vim is dangerous sometimes.

Status: Needs review » Needs work

The last submitted patch, 6: 2664150-6.patch, failed testing.

dawehner’s picture

In order to fix this properly we would need to have a way to distinct between WebTestBase tests and BrowserTestBase tests, in which case we would just throw the exception in the later case.

klausi’s picture

Just for reference we solved this a bit differently in Rules for now: https://github.com/fago/rules/blob/8.x-3.x/tests/src/Functional/RulesBro...

We have created methods on our browser test base class that perform web requests. At the end of each method we check the response for assertion headers. Primitive, but works.

fago also complained about this and we are seeking other solutions in #2659808: Improve browser tests to check for PHP errors and/or errors in watchdog.

dawehner’s picture

Status: Needs work » Needs review
FileSize
4.17 KB
523 bytes

Here is a bugfix

larowlan’s picture

  1. +++ b/core/lib/Drupal/Core/Test/HttpClientMiddleware/TestHttpClientMiddleware.php
    @@ -31,7 +33,21 @@ public function __invoke() {
    +          ->then(function (ResponseInterface $response) use ($request, $options) {
    

    $options doesn't look used?

  2. +++ b/core/lib/Drupal/Core/Test/HttpClientMiddleware/TestHttpClientMiddleware.php
    @@ -31,7 +33,21 @@ public function __invoke() {
    +                  $parameters = unserialize(urldecode($header_value));
    

    If simpletest module is enabled on a production site (yep someone might do that) - this could lead to unserializing user provided data. I think we should be checking drupal_valid_test_ua() here too - we're already passing in $request (but not using it?) - that way this code can't be run outside of the test-runner?

  3. +++ b/core/lib/Drupal/Core/Test/HttpClientMiddleware/TestHttpClientMiddleware.php
    @@ -31,7 +33,21 @@ public function __invoke() {
    +                  throw new \Exception($parameters[1] . ': ' . $parameters[0] . "\n" . Error::formatBacktrace([$parameters[2]]));
    

    Should we be defensive here and make sure that count($parameters) === 3.
    Personally I'd prefer list($something, $something_else, $something_else_again) = $parameters over the magic 0,1,2.

dawehner’s picture

Oh lovely testing system, the area where things are kinda nice.

larowlan’s picture

Status: Needs review » Reviewed & tested by the community

Thanks mate, looks good to me

  • alexpott committed 7cdd0e5 on 8.2.x
    Issue #2664150 by dawehner: Expand BrowserTestBase with error handling...

  • alexpott committed fde19db on 8.0.x
    Issue #2664150 by dawehner: Expand BrowserTestBase with error handling...
alexpott’s picture

Status: Reviewed & tested by the community » Fixed

Committed fde19db and pushed to 8.0.x, 8.1.x, 8.2.x since this only affects test code (and pretty experimental test code at that). Thanks!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.