Mastering UI automation at Scale: Key Lessons and Best Practices (By Fernando Martin)
0 likes1,218 views
The document discusses the development and implementation of UI automation using an augmented driver, covering lessons learned about parallelism, wait strategies, and encapsulating business logic through the page object model. It emphasizes the importance of maintaining test reliability and ease of integration with CI systems. The content includes technical code examples and recommendations for best practices in UI testing.
Mastering UI automation at Scale: Key Lessons and Best Practices (By Fernando Martin)
- 1. UI Automation at Scale Augmented Driver [email protected]
- 2. A little bit about me ● Started working @Google in late 2006.
- 3. A little bit about me ● Started working @Google in late 2006. ● Selenium/Webdriver started becoming a “thing” sometime in 2007.
- 4. A little bit about me ● In 2010 I joined Medallia.
- 5. A little bit about me ● In 2010 I joined Medallia. ● Super excited about building UI automation from scratch.
- 6. A little bit about me ● In 2014 moved to RelateIQ (Now SalesforceIQ)
- 7. A little bit about me ● In 2014 moved to RelateIQ (Now SalesforceIQ) ● Again a Start Up, being part of a small team that wanted to have a big impact in the company.
- 8. A little bit about me ● Finally a couple of months ago I joined Split.IO.
- 9. A little bit about me ● Finally a couple of months ago I joined Split.IO ● Being one of the first Software Engineers, again with the role of shipping code as fast as we can with the best Customer Experience as we can.
- 10. Episode I WebDriver tests are inherently slow. If you want throughput, you need to focus on parallelism, leading us to the first lesson in this saga.
- 11. Episode I: Data Independent Tests If each test creates its own data that is not shared with anyone else, then all of your tests can run in parallel.
- 12. To the code! @Path(“/test”) public class TestResource { @Post @Path(“create”) public Response create(String uniqueUser) { If (isProd()) { throw new NotAllowedException(“NOT ALLOWED”); } //… create unique user, organization, etc... //... } @Post @Path(“clean”) public Response clean(String uniqueUser) { If (isProd()) { throw new NotAllowedException(“NOT ALLOWED”);} //…clean unique user, organization, etc... //... } }
- 13. To the code! public class DataCreatorRule implements TestRule { public Statement apply(Statement statement, Description description) { return new Statement() { @Override public void evaluate() throws Throwable { String uniqueUser = "uniqueuser"; client .test() .create(uniqueUser); statement.evaluate(); client .test() .clean(uniqueUser); } } } }
- 14. To the code! public abstract class BaseTestCase { @Rule public DataCreatorRule dataCreatorRule =new DataCreatorRule(); }
- 15. Alternatives ● @BeforeMethod and @AfterMethod in TestNG. ● @Before and @After in JUnit < 4. ● beforeEach() and afterEach() in Jasmine JS. ● setUp(self) and tearDown(self) in Python.
- 16. Episode I Code Example
- 17. Episode II Throughput is achieved with Parallelism. With that in mind, you need to build reliable tests in all possible Environments. Local != Staging != SauceLabs. This leads to the second lesson...
- 18. Episode II: Slow and Steady Wins the Race Failures are caused by elements not showing up in time. In general, when the element has an unexpected transient state when the action is being performed.
- 19. To the code! private final Webdriver driver; public void ohWhy(By identifier) { Thread.sleep(3000); WebElement element = driver.findElement(identifier); element.click(); }
- 20. To the code! private final Webdriver driver; public void better(By identifier) { WebDriverWait wait = new WebDriverWait(driver, 10); WebElement element = wait.until(ExpectedConditions.elementToBeClickable(identifier); element.click(); }
- 21. To the code! private final AugmentedWebDriver driver; public void augmentedWay(By identifier) { driver .augmented() .findElementClickable(identifier) .click(); }
- 23. Episode II Code Example
- 24. Episode III. ● Your tests can run in parallel... ● You can wait until elements are on a desired state... Time to encapsulate you tests in business logic to maximize reusability and maintainability. This leads to the third lesson...
- 25. Episode III: Follow the Page Object Model Need to encapsulate the logic of the UI areas that your tests performs actions, for maintainability and for many other reasons.
- 26. To the code! public class MainPage extends WebPageObject { @Override public Optional<By> visibleBy() { return Optional.of(Bys.INPUT); } public static class Bys { public static class By INPUT = By.id("searchInput"); } }
- 27. To the Code! public class BaseCase extends AugmentedWebTestCase { public MainPage mainPage() { driver().get(“https://www.wikipedia.org”); Return get(MainPage.class); } }
- 28. Episode III Code Example
- 29. Episode IV ● Your tests can run in parallel... ● You can wait until elements are on a desired state... ● You have your framework encapsulated on business logic… The next level is to wait and expect certain business logic to take place when actions are performed. That leads to…
- 30. Episode IV: Wait and Expect for business logic This is an extension of the Episode 2 but at a much higher level that each app defines.
- 31. Episode IV: Wait and Expect for business logic Since now we have Page Objects that encapsulate business logic, we can perform “waiters” that will wait until certain condition is fulfilled.
- 32. To the Code! public class MainPage extends WebPageObject { public int numberOfSuggestions() { return driver() .augmented() .findElementSSSSVisible(Bys.SUGGESTION) .size(); } public static class Bys { public static final By SUGGESTION = By.className("suggestion-link"); } }
- 33. To the Code! @Test public void test() { mainPage .search("WebDriver"); waiter().waitUntil(mainPage, page -> page.numberOfSuggestions() > 3); }
- 34. Episode IV Code Example
- 35. Episode V ● Your tests can run in parallel... ● You can wait until elements are on a desired state... ● Your business logic is encapsulated... ● You can wait for business logic to be fulfilled… Now each test has maintainability and reliability in mind. It’s time to consolidate each individual piece into something that the rest of the team can easily digest it.
- 36. Episode V: Reporting Reporting Reporting This has one basic lesson learned:
- 37. Episode V DON’T
- 38. Episode V Code Example
- 39. Episode VI ● Your tests can run in parallel... ● You can wait until elements are on a desired state... ● Your business logic is encapsulated... ● You can wait for business logic to be fulfilled… ● You have a way to have visibility and transparency Finally the last step is to provide easy configuration and integrations so it can be plugged into CI systems
- 40. Episode VI: Integrations and Easy Configuration It should be easy and straightforward to integrate into different tools.
- 41. Episode VI Code Example
- 42. Thanks! Augmented Driver: https://github.com/relateiq/AugmentedDriver Split.IO: http://www.split.io/ Special offer by Applitools: 50-page guidebook to visual testing (including tips, tricks and code examples), written by Selenium expert Dave Haeffner. Claim your free copy by sending an email to [email protected]