Take advantage of WebDriverTestBase to deprecated PhantomJS for Chrome

I'm wondering if it is not enough to just swap BrowserTestBase for WebDriverTestBase in CommerceBrowserTestBase and remove some overrides we add in JavascriptTestTrait. Let's see how will it go.

Ah, of course, CommerceBrowserTestBase is also used by Functional tests - stupid me. Well, IMHO we should go for a new base class - CommerceWebDriverTestBase. And perhaps deprecate the JavascriptTestTrait there altogether?

I had the same conclusion after seeing tests failing and reading codebase focusing on how the tests were structured. And I agree that extracting reusable methods from each of the base classes and move it to the respective trait that will be later used across Functional and/or FunctionalJavascript tests is the way to go here. I don't have time to do it at this minute but I'll make a patch later this weekend.

Thanks for taking the time to answer here @mglaman.

That will still fail but this time only about web driver incompatible tests.

Ups, I should have checked that one before posting the patch.

That looks much better 😊

That should fix most of the tests. In fact, I only expect one remaining failure:

1) Drupal\Tests\commerce_cart\FunctionalJavascript\MultipleCartFormsTest::testUniqueAddToCartFormIds
Behat\Mink\Exception\UnsupportedDriverActionException: Response headers are not available from Drupal\FunctionalJavascriptTests\DrupalSelenium2Driver

What's the value of the following test code? Can we simply remove it?

    $this->assertSession()->responseHeaderNotEquals('BigPipe-Test-Placeholders', '<none>');
    $this->assertSession()->responseHeaderEquals('BigPipe-Test-No-Js-Placeholders', '<none>');

----
Edit:
BTW Something really strange happens when you set the value for date input (@see PromotionTest::testCreatePromotionWithEndDate). I had to change the format and the date itself so that it doesn't start with 0. I feel like this is an issue with chromedriver but couldn't easily debug it so I gave up and just changed the date.

But what's the exact reason we're checking if the headers are (not) ''? Is it used to ensure the page was loaded using big_pipe?

I can't find any test and/or patch file that would suggest there was a FunctionalJavascript test in core's big_pipe module that was using responseHeaderNotEquals/responseHeaderEquals in the past.

I only found this - https://github.com/drupalcommerce/commerce/pull/756#discussion_r126111860 - which is where we started testing this header in the first place.

It was my impression that these two assertions should just be removed. That's good we agree 👍

This looks good at a glance. Now we need to figure out how to make the tests work on Travis. That might require a PR to https://github.com/LionsAd/drupal_ti

I am testing it now here - https://travis-ci.org/zaporylie/commerce/jobs/448019594
Seems to be working fine 🎊

or is it really :/
Jobs were terminated after 50 minutes due to a maximum time limit. Not sure if that's travis being slow or something wrong with the chromedriver.

It must be something related to the modified webdriver setup. The time spent on Unit/Kernel/Functional is more or less the same as before but FunctionalJavascript takes much longer.