Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Follow-up to #2887869: Convert web tests to browser tests for user module part-2
Scope of conversion:
- UserBlocksTest's testWhosOnlineBlock to KTB
- UserRegistrationTest's JS part (drupalPostAjaxForm) in testRegistrationWithUserFields to JTB.
Once the patch for JTB is in, remove testRegistrationWithUserFields from https://www.drupal.org/node/2887869#comment-12172409.
Comment | File | Size | Author |
---|---|---|---|
#80 | interdiff-2895271-74-80.txt | 1.87 KB | ApacheEx |
#80 | 2895271-80.patch | 14.36 KB | ApacheEx |
Comments
Comment #2
navneet0693 CreditAttribution: navneet0693 as a volunteer and at QED42 commentedThis patch only contains UserWhosOnlineBlock kernel test.
Comment #3
LendudeNice! Happy to see you got it running!
Since we are only dealing with the conversion of 2 tests in this patch I think we can deviate from the normal policy of keeping the changes minimal.
"Tests the Who's Online block." I'd say
No need to prefix with User since we have the namespace to let us know we are dealing with a user test.
I'd would prefer a fixed string for these fields, why randomly generate one?
Extra newline not needed
Lets use valid email addresses (so with an @ somewhere), and lets make them unique
Request time is deprecated, lets not use it
entity_view is deprecated, lets not use it
Comment #4
navneet0693 CreditAttribution: navneet0693 as a volunteer and at QED42 commentedComment #5
dawehnerGiven that there is just one place where you actually use it, you could remove it to be a class member and make it a local variable.
Did you tried using
$this->render()
in the kernel test base? This could make things a little bit easier.Comment #7
navneet0693 CreditAttribution: navneet0693 as a volunteer and at QED42 commentedThanks @dawehner. I did the changes.
One question for converting drupalPostAjaxForm to JTB for UserRegistrationTest:: testRegistrationWithUserFields().
Refer: http://cgit.drupalcode.org/drupal/tree/core/modules/user/src/Tests/UserR...
Do I need to write a same test function again with relative changes just for testing js part? If not, please guide me with the steps.
Comment #9
navneet0693 CreditAttribution: navneet0693 as a volunteer and at QED42 commentedOuch! that is not suppose to happen, but somehow it did :-( attaching a screenshot of local test results.
Comment #10
navneet0693 CreditAttribution: navneet0693 as a volunteer and at QED42 commentedAdded the test again, and it passed ! Hurray, now working on adding JTB.
Comment #11
navneet0693 CreditAttribution: navneet0693 as a volunteer and at QED42 commentedAdding JTB, it needs reviews. RegistrationWithUserFieldsTest.php is failing at Line 114.
Added interdiff which only contains RegistrationWithUserFieldsTest.php for easy review.
Comment #12
navneet0693 CreditAttribution: navneet0693 as a volunteer and at QED42 commentedPlease ignore patch in #11. Failure reasons are same though.
Comment #14
navneet0693 CreditAttribution: navneet0693 as a volunteer and at QED42 commentedComment #15
navneet0693 CreditAttribution: navneet0693 as a volunteer and at QED42 commentedComment #17
navneet0693 CreditAttribution: navneet0693 as a volunteer and at QED42 commentedComment #18
navneet0693 CreditAttribution: navneet0693 as a volunteer and at QED42 commentedComment #20
navneet0693 CreditAttribution: navneet0693 as a volunteer and at QED42 commentedI am kind of stuck here:
Just after first click, I can see that *please wait* is appearing content output, which says that button is getting clicked. But it's not getting added.
Comment #21
navneet0693 CreditAttribution: navneet0693 as a volunteer and at QED42 commentedComment #22
navneet0693 CreditAttribution: navneet0693 as a volunteer and at QED42 commentedComment #24
LendudeSomething like this should do the trick to get it green.
This still needs cleaning up though:
replace all the assertWaitOnAjaxRequest() with waitForElement()
why is there a js and nojs version? both use javascript since its enabled for this test, it doesn't matter how you click on the button
Comment #25
navneet0693 CreditAttribution: navneet0693 as a volunteer and at QED42 commentedComment #26
dawehnerCan we avoid the JSWebAssert, given it will be not the recommended way anymore in the future?
Comment #27
navneet0693 CreditAttribution: navneet0693 as a volunteer and at QED42 commentedDo we want to simply rely on WebAssert ?
Comment #28
dawehner@navneet0693
Yes, it does all you need.
Comment #29
dawehnerIt is a pure implementation detail that its returning a
JSWebAssert
right now.Comment #30
navneet0693 CreditAttribution: navneet0693 as a volunteer and at QED42 commentedComment #32
navneet0693 CreditAttribution: navneet0693 as a volunteer and at QED42 commentedRunning tests again!
Comment #34
navneet0693 CreditAttribution: navneet0693 as a volunteer and at QED42 commentedAdding test against 8.5.x.
Comment #36
pasan.gamage CreditAttribution: pasan.gamage at PreviousNext commentedThe only things I could find in this are documentation issues.
These need comment.
These should be protected
Comment #37
navneet0693 CreditAttribution: navneet0693 as a volunteer and at QED42 commentedComment #38
pasan.gamage CreditAttribution: pasan.gamage at PreviousNext commentedLooking good.
Thanks @navneet0693
Comment #39
larowlanCouple of minor questions
Should we keep this in a local variable the first time so we can edit and save it without needing to reload?
nit: extra line
Comment #40
larowlanAdding review credits
Comment #41
navneet0693 CreditAttribution: navneet0693 as a volunteer and at QED42 commentedComment #42
JayKandariThanks @navneet !! This addresses #39 :)
Comment #45
larowlanCommitted as 26aebd3 and pushed to 8.6.x.
cherry-picked as 274d50c and pushed to 8.5.x
Thanks
Comment #47
larowlanThis broke head, reverted
Comment #49
navneet0693 CreditAttribution: navneet0693 as a volunteer and at QED42 commentedRe-testing : https://www.drupal.org/pift-ci-job/872812
Comment #50
navneet0693 CreditAttribution: navneet0693 as a volunteer and at QED42 commentedTests passed: https://dispatcher.drupalci.org/job/drupal_patches/46377/console
Comment #51
navneet0693 CreditAttribution: navneet0693 as a volunteer and at QED42 commentedComment #52
larowlanSo looks like the test was failing on php 5.6
Can you reproduce that locally?
Comment #53
navneet0693 CreditAttribution: navneet0693 as a volunteer and at QED42 commented@larowlan Nope, the tests passed with php5.6 also, attaching screenshot for the same.
Comment #54
larowlanIf it still fails, perhaps run locally with
--php=`which php56`
just to be 100% sure that run-tests.sh is picking up the correct php versionComment #55
navneet0693 CreditAttribution: navneet0693 as a volunteer and at QED42 commentedAnd all tests are green now !
Comment #56
LendudeDoesn't feel very stable though. Requeued again, lets get some more passes on this.
Comment #57
navneet0693 CreditAttribution: navneet0693 as a volunteer and at QED42 commentedSetting it to 'Needs Work' . @Lendude @larowlan This is unstable, I can reproduce on local. The test passes on first attempt, but fails in second attempt. And this is same result we can see on drupalci test runner.
Attaching screenshot:
Comment #58
navneet0693 CreditAttribution: navneet0693 as a volunteer and at QED42 commentedComment #59
MixologicWhat happens if you add a user who's last access time is far into the future? Are they considered active ? it may be that the +1 here is causing them to be in the future and if the test completes fast enough, they are not considered active, but if the test is slow enough they are.
Two things I would recommend to sort out a flapping test like this.
I would resubmit the patch, except add some changes to run-tests.sh where it *only* has this one test, and sets the repeat to something high, like 100.
then I would look at the simpletest build artifacts directory, and in it you will find the html output for that one test, as those are being saved now (we cant save them for full core runs because they're 500mb and 36000, files, but they'd show up for on e thats just on repeat)
https://dispatcher.drupalci.org/job/drupal_patches/46610/artifact/jenkin... is an example of where you would find those.
Comment #60
larowlanlet's put this into a variable and make the tolerance bigger for the inactive one.
And then follow @Mixologic's suggestion of uploading a patch that hacks run-tests.sh just to run this test several times
Comment #61
navneet0693 CreditAttribution: navneet0693 as a volunteer and at QED42 commented@Mixologic thanks ! I will try that. @larowlan Sure, but I wonder why there's no such random failure with http://cgit.drupalcode.org/drupal/tree/core/modules/user/src/Tests/UserB... which same logic.
Comment #62
navneet0693 CreditAttribution: navneet0693 as a volunteer and at QED42 commentedComment #63
borisson_We still need that test ran several times, to make sure we don't introduce new random failures.
Comment #64
LendudeI wanted to update to SeleniumDriver which leads to a new problem that the javascript test can't test the cache tags set in the headers.
So to solve this, we can just leave the BTB version as is, without the js-nojs switch. Do the things we can do in Javascript test and then we still have the same coverage.
Other issue, when leaving a required field blank, chrome detects this and the form never submits, which means we can't check the validation messages. This is what happens locally anyway, lets see what happens on Drupal CI.
Comment #66
ziomizar CreditAttribution: ziomizar at Station commentedThis remove the browser validation and let drupal check the required field.
I've also removed the call to the method that test the cache.
Comment #68
Lendude@ziomizar nice! The remaining fail is just that the javascript test now needs to extend WebDriverTestBase and not JavascriptTestBase.
Comment #69
ziomizar CreditAttribution: ziomizar at Station commentedFix as suggested in #68, lets see if we get a green..
Comment #70
navneet0693 CreditAttribution: navneet0693 as a volunteer and at QED42 commentedRe-adding tests to be more sure !
Comment #71
LendudeThis is looking great! Just some minor clean up needed I think:
This is the default in WebDriverTestBase so this can be removed
This can just be {@inheritdoc} in the new test.
Love the workaround. Doc could be a little more descriptive maybe. Maybe something like:
In order to check the server side validation the native browser validation for required fields needs to be circumvented.
Comment #72
ApacheEx CreditAttribution: ApacheEx as a volunteer and at Drupal Ukraine Community commentedHere is improved patch from #69 based on Lendude's comment ;)
Comment #74
ApacheEx CreditAttribution: ApacheEx as a volunteer and at Drupal Ukraine Community commentedOnce more :)
Here is improved patch from #69 based on Lendude's comment ;)
Comment #75
Lendude@ApacheEx Thank you!
All feedback has been addressed.
Comment #76
alexpottJust wondering how come we're not removing \Drupal\user\Tests\UserBlocksTest::testWhosOnlineBlock() since we've moved it to a kernel test?
Comment #77
Lendude@alexpott woops! Way to focussed on the javascript part of this! Nice catch.
Yeah we need to remove
\Drupal\user\Tests\UserBlocksTest::testWhosOnlineBlock
Comment #78
navneet0693 CreditAttribution: navneet0693 as a volunteer and at QED42 commented@Lendude @alexpott The patch here removes it: https://www.drupal.org/project/drupal/issues/2887869#comment-12375166
Comment #79
alexpott@navneet0693 yes but we should remove it here as the change here makes
\Drupal\user\Tests\UserBlocksTest::testWhosOnlineBlock()
obsolete.Comment #80
ApacheEx CreditAttribution: ApacheEx as a volunteer and at Internetdevels, Drupal Ukraine Community commentedNice catch, here is updated patch.
Comment #82
Lendude@ApacheEx thanks!
Comment #83
alexpottAdding review credit to @alexpott and @Mixologic for patch reviews.
Committed and pushed 9fc5c5965a to 8.7.x and a538cef929 to 8.6.x. Thanks!
Fixed coding standards on commit.