Selenium at Salesforce Scale Greg Wester Principal Engineer @gwestr in/gwester

• About Salesforce engineering • Operating a selenium farm • Selenium design patterns • Overcoming test failures • Q&A Agenda

Salesforce Scale • 3:2 ratio for developers : quality engineers • everyone is a software engineer; role varies • 2 selenium committers on staff (Jim Evans, Luke Inman) • 50,000 VM data center for automated tests • multimillion dollar investment • 500 commits per day • ~120 software engineering teams

Why Salesforce loves WebDriver WebDriver is the only test framework in our current arsenal that truly mimics an end-user’s experience • We don’t mock anything • We test against a live app • We suffer the pain of latency • We test end to end on almost every action WebDriver tests can catch things other levels of tests can’t • Multi-platform consistency • DOM consistency • Rendering issues • Piping between app layers source: watirmelon.com © Alister Scott

UI Testing Portfolio • 50,000 unique Selenium tests • 7,500 unique WebDriver tests • full “browser compatibility”: IE6-IE11, Firefox, Chrome, Safari • some can run in headless browser like Phantom JS • 2,000 javascript unit tests • no DOM required • 10ms average execution time source: watirmelon.com © Alister Scott

1,000,000 browser tests per day • Click here to add bullets

Issues of scale • Assigning test failures to the responsible engineer • Non deterministic tests (flappers) and re-runs • Selenium jar upgrades are challenging • Browser upgrades are challenging • IT and automation ops provide different versions • Large suites: adjust run frequency, deprecate old tests

Salesforce UI Testing Pattern • Click here to add bullets

Proper Page Objects Encapsulate Selenium • Make an API of your page for your test • No imports for “openqa” or “selenium.org” in your test • All references to driver & selenium in the page object • Fail fast - call the page object factory in test setup • No assertions in page objects (or any test utility) • Share page objects across engineering teams • developer complete UI should have a page object • if you can’t make one it’s not a testable page • dependency challenges at scale

Challenges for Mobile Platforms • Adapting page objects to platform specific UI elements • Screen sizes and adaptive layouts • cards • “stage left” • lightweight page objects = widgets • Avoid browser or platform specific code in actual tests • establish context elsewhere in utils or page objects • Automated tests in emulators (99%+) • manual tests on devices before release • exception: testing video

Sagar Wanaselja Lead Engineer [email protected]

Problematic WebDriver Test

Better WebDriver Test

PageObject WebDriver Test

Diagnosing Test Failures • Screenshot and HTML capture at failure point • AssertionError or RuntimeException • Differences between localhost and automation VM • Optimistic timing assumptions • javascript, rendering, server response, etc. • Defensive “negative” testing • Getting to 100% tests passing

Pro Tips • Version tests and app code (and configuration) together • Use the Page Object model • Use the API to set up the test, not the UI • Anticipate Selenium and Browser releases • Allocate capacity to browsers most used by customers • log the user agent on every page view

More Pro Tips • Avoid using xpath selectors • Complex DOM makes xpath evaluation much slower • Some xpaths are not properly evaluated in WebDriver • When working with pop ups make sure you return focus to the main window • For static HTML pages consider HTML Unit

Mature Quality Strategies • Selenium for dynamic security vulnerability analysis • Pixel perfect image diffs • Accessibility testing (tab completion) • Testing javascript with unit tests • Selenium is for testing browser compatibility and DOM

No content