At Mozilla, a lot of work has been done to try to promote best practices around cross browser testing, as although many of us are working carefully to ensure cross browser compatibility of our products, many developers don’t test across many browsers outside the top one or two. A large part of this is education — many devs, particularly those towards the client-side end of the equation, find cross browser tools tricky to set up. Many new devs are learning their trade through courses that only show testing in one browser - hard to believe in 2016 - and don’t learn command line skills, or setting up tools like Selenium, etc. To this end, Mozilla started a campaign to educate devs, starting with research, the current state of the industry, and business cases for cross browser testing (See https://hacks.mozilla.org/2016/07/make-the-web-work-for-everyone/). They they went on to create learning material to fill the gap between fundamental front end skills, and successful cross browser testing, and partnered with Sauce Labs to provide easier access to tools. The learning module can be found here: https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing In this talk, Mozilla’s Chris Mills talks about some of this work including: * The important of cross browser testing * Deciding on what to include in the learning module * What he learned along the way * What he found easy and difficult as someone coming from the front-end dev world.

1. Winning the fight
against test
automation
Chris Mills Mozilla

2. Who am I?
‣ Tech writer at Mozilla
‣ Writes about Web APIs on MDN
‣ Heads up the MDN Learning Area
‣ HTML.CSS.JS tinkerer
‣ Accessibility whinge bag
‣ Heavy metal drummer

4. In this talk
‣ The importance of cross browser testing
‣ What I wrote about it
‣ What I learned
‣ What was easy (and difficult)

5. Cross browser testing

6. (Important!)
‣ More than 1BN websites
‣ 3BN web users
‣ 8.1BN connected devices
‣ 24,000 mobile device types
‣ Lots of different browsers
‣ ~20% of users have a disability

7. Why don’t we?
‣ Less experience of X browser issues
‣ Many courses only teach Chrome
‣ Over-reliance on bleeding edge features
‣ And vendor-prefixed features

8. Other x-browser
issues
‣ Browser vendors can be slow to fix bugs
‣ Some people still use browser sniffing
rather than feature detection

9. And of course
‣ Toolchain/workflow perceived as difficult

10. So I wrote about it

11. We had to!
‣ Cross browser testing (MDN)
‣ Beginner-friendly guide to X browser
‣ Also friendly to front-end devs

12. Fitting it in
‣ What is X browser testing?
‣ Where + when should it happen?
‣ What should you test?
‣ How do you test it?

13. Solving common
problems
‣ HTML
‣ CSS
‣ JavaScript
‣ Accessibility

14. Automating tests
‣ Task runners
‣ Selenium automation
‣ SauceLabs
‣ SauceLabs + Selenium

15. What was easy?

16. The webby stuff
‣ Of course!
‣ HTML/CSS/JavaScript is second nature
‣ We also know our accessibility
‣ And our browsers!

17. Writing the tests
‣ Selenium test logic is fairly easy (once
you’ve got it working)
‣ Writing/running the tests was easy (I used
Node); modules seem to have good docs
‣ SauceLabs integration was easy

18. Accessing WD
var webdriver = require('selenium-webdriver'),
By = webdriver.By,
until = webdriver.until;
var driver = new webdriver.Builder()
.forBrowser('firefox')
.build();

19. Accessing a page
driver.get('http://www.google.com');
driver.findElement(By.name('q')).sendKeys('webd
river');
driver.findElement(By.name('btnG')).click();

20. Running a test
driver.sleep(2000).then(function() {
driver.getTitle().then(function(title) {
if(title === 'webdriver - Google Search') {
console.log('Test passed');
} else {
console.log('Test failed');
}
});
});

21. Finishing up
driver.quit();

22. Accessing SauceLabs
var webdriver = require('selenium-webdriver'),
By = webdriver.By,
until = webdriver.until,
username = "YOUR-USER-NAME",
accessKey = "YOUR-ACCESS-KEY";

23. Accessing SauceLabs
var driver = new webdriver.Builder().
withCapabilities({
'browserName': 'chrome',
'platform': 'Windows XP',
'version': '43.0',
'username': username,
'accessKey': accessKey
}).
usingServer("https://" + username + ":" + accessKey +
"@ondemand.saucelabs.com:443/wd/hub").
build();

24. Updating SauceLabs
var saucelabs = new SauceLabs({
username : "YOUR-USER-NAME",
password : "YOUR-ACCESS-KEY"
});

25. Accessing SauceLabs
driver.getSession().then(function (sessionid){
driver.sessionID = sessionid.id_;
});

26. Accessing SauceLabs
if(title === 'webdriver - Google Search') {
console.log('Test passed');
var testPassed = true;
} else {
console.log('Test failed');
var testPassed = false;
}
saucelabs.updateJob(driver.sessionID, {
name: 'Google search results page title test',
passed: testPassed
});

27. What was hard?

28. Setting up Selenium
‣ Working out what to use in the first place
‣ There’s lots of docs…
‣ …and they can be confusing

29. Setting up Selenium
‣ Do you use WebDriver, or Selenium Server,
or Selenium RC, or Selenium Grid, or… ?
‣ Finding drivers for all the browsers you want
to automate
‣ Installing the modules (or whatever) that
you need for your server-side environment
‣ Making sure everything is communicating

30. We could benefit from
‣ Simple guides based on other server-side
environments
‣ Better API docs for the SauceLabs API

31. Finito!
‣ Make the web work for everyone (Hacks)
‣ Cross browser testing (MDN)
‣ slideshare.net/chrisdavidmills
cmills@mozilla.com @chrisdavidmills