Drupal FunctionalJavascript testing

About you

You are a Drupal, Symfony, or any kind of PHP dev and are looking for help with a peculiar aspect of unit testing (see title above), a tale from the crypts, or nap time story that will put you to sleep. Probably a combination of all of those. Otherwise you should probably move along 😉

The context

I’m testing a OAuth implementation between Drupal and SoundCloud and using Drupal’s functional suite to do so. The rest of my module is using either kernel or regular unit tests. But for OAuth it’s either a mock (see tests for Martin1982OAuth2 on Packagist), or a live call.

I already looked at some mocking methods and I don’t like them, too fake; I know, hot take. The SoundCloud service decommissions your access if you do not use it. Baking a live OAuth call into the testing helps keep the access alive (otherwise you’d have to wait months for re-authorization).

I’m aiming to TDD the heck out of a contrib module I’m doing for fun, and so leaving stones unturned (in testing) is not an option. This is our definition of fun in the development department.

Not trying to say one way (mocking) is better than the other (live call), or that there is a right answer. I’m not going to Joel Spolsky this post either. I’m just going with my gut feeling and documenting the process.

Why this post

I already lost the opportunity to document other fixes/discoveries/tips I’ve done so far with regards to “functional javascript” unit testing today, and so that’s why I am starting this post.

I know that not in a week, but rather by tomorrow I’ll forget the details because they’re too many to keep track of. Not a bug of this business, just a feature. Documenting stuff somewhere is how we deal with this … loss of context.

Also the sooner I can start dumping my browser tabs somewhere else other than a session saver or OneNote, the faster that I can close them up. Marie Kondo would not approve of the amount of tabs I have open, and neither do I! The thing I hate about dumping an entire browser session is that I’ll barely revisit those while hunting for a resource. And OneNote just gets out of control, too… many… notes

Needless to say, you should know this is a raw post. There is no editing. There is no shiny merchandising material, alt coins or artificial intelligence involved.

Anyways.

Before PHPUnit was having trouble connecting to Chrome. A quick telnet in the Lando appserver container confirmed that Chrome was indeed up and reachable by the PHP container:

And before that I dealt with

The link (with fix) to that notice is https://www.drupal.org/node/3422624.

I prefer to use environment variables to configure the unit testing because they’re easier to access than phpunit.xml. While I’ve set them before in the Lando config file, setting things in Lando means that you have to rebuild and restart the whole stack for environmental changes to take effect. Time, it just adds up, man.

Instead I put it in a bash helper called by Lando tooling. This is the env var:

Fixing the (second) connectivity issue

My Lando chrome spec needed to be updated to add the allowed origins flag to the chromedriver:

Note that there is a myriad chromedriver images out there, and that the drupalci happens to be the one mentioned by either Lando or Drupal.org documentation (maybe).

Credit for that fix is in Github, thanks to user @Niklan.

Access is denied and invalid cookie domain

Mink is reporting Failed to read the ‘sessionStorage’ property from ‘Window’: Access is denied for this document.

PHPUnit is reporting
Test Skipped (DrupalTestsmusicaFunctionalJavascriptFooTest::testMyFirstJavasScriptTest)
An unexpected error occurred while starting Mink: invalid cookie domain

T.B.C.

I still have 30 or so browser tabs open (lol) and have to hunt this one down.

Love spending time on testing infrastructure instead of “actual code” (sarcasm).

It’s well past beyond midnight and tomorrow is another day. I’ll come back to update this post as I move along.

T.B.C. …