To ease conversion from WebTestCase, we're adding a bc layer to browsertestbase so that assertions don't have to be converted when tests are.

Some of these might be deprecated, some might be actually useful and need to be part of the API.

This should happen before conversions land so that there is minimal work to do apart from the conversion itself.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes


catch created an issue. See original summary.

catch’s picture

dawehner’s picture

Well, we already have this BC layer, we just expand it over time.

dawehner’s picture

Ignore my previous comment, well this is just a tracking issue.

catch’s picture

Title: Add backwards compatibility layer to browsertestbase to ease conversion from webtestcase » [meta] Add backwards compatibility layer to browsertestbase to ease conversion from webtestcase

Let's make that more obvious from the title :)

dawehner’s picture

dawehner’s picture

jmuzz’s picture

I have been converting some tests to BTB and I noticed a few small but common changes that had to be made several times. I'm wondering if they should be fixed in BTB rather than the individual tests, if only temporarily for this issue and #2770921: Feb 21st: Convert chunk of WTB to BTB by just moving classes, changing use statements adding traits.

  • Most drupalPostAjaxForm() calls can be changed to drupalPostForm() without any side effects. BTB could implement it as an alias.
  • Calls to dropalPostForm() that use NULL as the second parameter need to be changed to [] or array(). BTB could accept NULL as equivalent.
  • I have been changing calls to clickLink() that use the second argument ($index) to click() and specifying the link via CSS selectors because BTB ignores the second argument. Support for it could be re-added to BTB.

Thoughts? I could create separate issues if these seem like good ideas.

klausi’s picture

Good ideas, I'm not sure about drupalPostAjaxForm() because those tests should really be converted to JavascriptTestBase if they need to test AJAX functionality. Yes, please create those child issues!

dawehner’s picture


klausi’s picture

klausi’s picture

Oh, and we have decided to NOT provide compatibility for drupalPostAjaxForm(). Instead, we will convert those tests doing AJAX to proper JavasscriptTestBase tests. See #2809161: Convert Javascript/AJAX testing to use JavascriptTestBase.

catch’s picture

Yep +1 to #12, better to convert once to the right thing.

dawehner’s picture

Added #2820182: Add a LegacyBrowserTestBase which uses every legacy trait we have to make things a bit easier with the trait conversions.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

klausi’s picture

michielnugter’s picture

Issue tags: +phpunit initiative
dawehner’s picture

Status: Active » Fixed

I think we have a path for individual conversions now, so I don't consider this as be longer useful. Feel free to disagree and reopen the issue :)

Mile23’s picture

There are still some pending child issues...

Status: Fixed » Closed (fixed)

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