Comments

nlisgo created an issue. See original summary.

nlisgo’s picture

Following the steps to convert the one test file Drupal\tracker\Tests\TrackerTest to Drupal\Tests\tracker\Functional\TrackerTest was mostly successful but fails on only one assertion:

Drupal\Tests\tracker\Functional\TrackerTest::testTrackerUser ($this->assertEscaped('<em>' . $this->user->id() . '</em>');)
nlisgo’s picture

Status: Active » Needs review
FileSize
38.7 KB

Without the resetAll and rebuildContainer then the user_hooks_test_user_format_name_alter hook was not registered. Installing the module user_hooks_test alone was not enough.

As instructed by @Lendude I have left the views simpletests in place.

nlisgo’s picture

Assigned: nlisgo » Unassigned
Lendude’s picture

@nlisgo could you reroll the patch with -M?

nlisgo’s picture

pfrenssen’s picture

Without the resetAll and rebuildContainer then the user_hooks_test_user_format_name_alter hook was not registered. Installing the module user_hooks_test alone was not enough.

Under which conditions was this happening? When I run the test on the latest 8.4.x it works fine without $this->resetAll() and $this->rebuildContainer().

The patch looks fine!

nlisgo’s picture

@pfrenssen when I switched the test to phpunit it did not work without the resetAll and rebuildContainer.

Without this the user_hooks_test_user_format_name_alter hook did not fire.

nlisgo’s picture

michielnugter’s picture

I tested the patch and for me the rebuildContainer() wasn't required to make it work, the resetAll() was required though.

I tried changing:

\Drupal::service('module_installer')->install(['user_hooks_test']);

To use the local container:

$this->container->get('module_installer')->install(['user_hooks_test']);

But that didn't improve it. It really seems like the resetAll() is required now.

michielnugter’s picture

pfrenssen’s picture

Status: Needs review » Reviewed & tested by the community

OK, fair enough, for me it worked without those additional lines, maybe it's the PHP version or something.

alexpott’s picture

Status: Reviewed & tested by the community » Needs work
+++ b/core/modules/tracker/tests/src/Functional/TrackerTest.php
@@ -208,6 +208,7 @@ public function testTrackerUser() {
     \Drupal::service('module_installer')->install(['user_hooks_test']);
+    $this->resetAll();
     Cache::invalidateTags(['rendered']);

I think we really need to understand why the conversion to BrowserTestBase necessitates this change. For the people where the tests doesn't work without it - does the Simpletest WebTestBase pass locally or does it fail?

Lendude’s picture

@alexpott yeah figuring it out now makes sense.

Here is the patch without any additional clearing. It works for me fine when running PHP7.0.13 but lets run this on a couple of different PHP versions on D.O. and see what happens here.

The last submitted patch, 14: interdiff-2863268-10-14.patch, failed testing.

Lendude’s picture

Ok so it fails on 7.1, but not 7.0. @nlisgo did you run 7.1? Can't remember.

Queued #11 for 7.1 too, and lets see what that does.

michielnugter’s picture

Interesting, I was running PHP 7.1, maybe it's related to that. I have similar problems with the DisplayTest test in the views_ui conversion (#2747167: Convert first part of web tests of views_ui), going to try without the resetAll() on the testbot as well.

Lendude’s picture

Ok so with only the resetAll it still fails on 7.1, testing #6 on 7.1 and lets see it that passes with both extra operations

michielnugter’s picture

All fails on 7.1 seem out of scope of this issue as they are for OptionsFieldUITest and nothing in the patch changed anything that could make this test fail right?

Everything this test changes, passes in all versions thus the resetAll() doesn't seem required for the testbot. I am curious though why it seems required locally, will try to dig deeper into this.

Lendude’s picture

Ha! Well spotted @michielnugter, yeah that fail on 7.1 looks unrelated. So the patch #14 should be the way to go.

michielnugter’s picture

HEAD isn't broken though on these tests, I still want that figured out before setting on RTBC again, feels like a risk otherwise.

Lendude’s picture

07:12:05 Segmentation fault (core dumped)
07:12:05 FATAL Drupal\Tests\options\Functional\OptionsFieldUITest: test runner returned a non-zero error code (139).
07:12:05 Drupal\Tests\options\Functional\OptionsFieldUITest 0 passes 1 fails

See #2829040: [meta] Known intermittent, random, and environment-specific test failures and point 5 under 'If your patch has an unexpected test failure', just added by xjm. So it would seem the fails are unrelated....

dawehner’s picture

I triggered a couple of test failures, I think we can be sure that its safe?

Lendude’s picture

Yeah I think that this is safe, just weird that at some point it seemed to be triggering seg faults in other tests, but I don't really see how that can be caused by moving two files.

michielnugter’s picture

Rerunning tests for each php version again, if it holds up I'll RTBC.

dawehner’s picture

Status: Needs review » Reviewed & tested by the community

All of them went green.

alexpott’s picture

Status: Reviewed & tested by the community » Fixed

Committed and pushed 5ed519d to 8.4.x and c631b5e to 8.3.x. Thanks!

Backported to 8.3.x because this is tests only and keeps the two active branches in sync.

  • alexpott committed 5ed519d on 8.4.x
    Issue #2863268 by nlisgo, Lendude, michielnugter: Convert web tests to...

  • alexpott committed c631b5e on 8.3.x
    Issue #2863268 by nlisgo, Lendude, michielnugter: Convert web tests to...

Status: Fixed » Closed (fixed)

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