DrupalCon Amsterdam 2014: The Future of Drupal Functional Testing
Speakers: nick_schuchlarowlangrom358everzet
This is your opportunity to shape the way we test Drupal!
In the Drupal 8 cycle we have invested alot of time into writing tests. We are now writing unit tests for our logic and acceptance tests for our scenarios, but what about our frontend (Javascript) testing?
Originally Drupal's WebTestBase evolved from SimpleTest but over the years it has morphed and transformed into a mutant beast of difficult to maintain custom code.
Whilst we've been off on our island, the PHP community at large have been working together on solving the same problems we've been adding additional band-aids and bolt-ons to SimpleTest for.
One such solution is Mink.
Say hello to Mink
Many of us are familiar with Behat's gherkin syntax but you may not be aware that the real power of Behat is powered by Mink. Most of the built in step-definitions are added by the Mink extension, which is a Behat Extension that wraps Mink.
The core of Mink is the DriverInterface which allows a swappable back-end for functional testing.
Much of the custom code we have in SimpleTest can be handled by existing functionality in Mink, but in a back-end independent manner.
Since Early April 2014, the three of us have been Re-architecting WebTestBase on top of Mink but retaining as much backwards-compatibility as possible.
So at present in WebTestBase when a test calls $this drupalGet the implementation is hard-wired to use curl.
This means that we are limited in our web-testing to things that Curl can handle. As a result we have some interesting work-arounds for JavaScript/Ajax handling (we are looking at you drupalPostAjaxForm).
With WebTestBase rearchitected on top of Mink, we maintain a Mink session for browser interactions. The default implementation of this would use the Goutte driver, which is simple web-scraper that wraps Guzzle and the Symfony DomCrawler component. So with the new code $this drupalGet hands off to the driver, what the driver does is up to it, WebTestBase need not care.
So how does this help Drupal?
We get rid of loads of custom-code for parsing/manipulating the dom and just use widely adopted implementations.
We get rid of loads of custom Curl handling code and let Goutte and Guzzle worry about it.
Any issues we find strengthen those code-bases. We've already ported Goutte to Guzzle 4 - i.e. Goutte 2.0. We've found and fixed bugs in Guzzle 4. PIE for the win.
We can move towards real JavaScript testing
Wait how does this help JavaScript testing?
So imagine JavaScriptTestBase extends WebTestBase but instead of using the Goutte driver in our session, we instead use the Selenium, Sahi or Zombie drivers - these drivers understand JavaScript - they are either headless browser implementations or they control real browsers.
Or in code terms.
This is your opportunity to shape the way we test Drupal!
In the Drupal 8 cycle we have invested alot of time into writing tests. We are now writing unit tests for our logic and acceptance tests for our scenarios, but what about our frontend (Javascript) testing?
Originally Drupal's WebTestBase evolved from SimpleTest but over the years it has morphed and transformed into a mutant beast of difficult to maintain custom code.
Whilst we've been off on our island, the PHP community at large have been working together on solving the same problems we've been adding additional band-aids and bolt-ons to SimpleTest for.
One such solution is Mink.
Say hello to Mink
Many of us are familiar with Behat's gherkin syntax but you may not be aware that the real power of Behat is powered by Mink. Most of the built in step-definitions are added by the Mink extension, which is a Behat Extension that wraps Mink.
The core of Mink is the DriverInterface which allows a swappable back-end for functional testing.
Much of the custom code we have in SimpleTest can be handled by existing functionality in Mink, but in a back-end independent manner.
Since Early April 2014, the three of us have been Re-architecting WebTestBase on top of Mink but retaining as much backwards-compatibility as possible.
So at present in WebTestBase when a test calls $this drupalGet the implementation is hard-wired to use curl.
This means that we are limited in our web-testing to things that Curl can handle. As a result we have some interesting work-arounds for JavaScript/Ajax handling (we are looking at you drupalPostAjaxForm).
With WebTestBase rearchitected on top of Mink, we maintain a Mink session for browser interactions. The default implementation of this would use the Goutte driver, which is simple web-scraper that wraps Guzzle and the Symfony DomCrawler component. So with the new code $this drupalGet hands off to the driver, what the driver does is up to it, WebTestBase need not care.
So how does this help Drupal?
We get rid of loads of custom-code for parsing/manipulating the dom and just use widely adopted implementations.
We get rid of loads of custom Curl handling code and let Goutte and Guzzle worry about it.
Any issues we find strengthen those code-bases. We've already ported Goutte to Guzzle 4 - i.e. Goutte 2.0. We've found and fixed bugs in Guzzle 4. PIE for the win.
We can move towards real JavaScript testing
Wait how does this help JavaScript testing?
So imagine JavaScriptTestBase extends WebTestBase but instead of using the Goutte driver in our session, we instead use the Selenium, Sahi or Zombie drivers - these drivers understand JavaScript - they are either headless browser implementations or they control real browsers.
Or in code terms.