Readable. Stable. Maintainable. E2E Testing @ Facebook | Archit Pal Singh Sachdeva
At Facebook we use end-to-end tests to ensure the quality of our website and suite of apps. Most of those tests have their roots in WebDriver, however, at that scale with multiple people writing and maintaining tests some issues with WebDriver emerged. Tests were becoming long and hard to read: flaky due to explicit waiting and stale element references, especially with React and highly dynamic UI; hard to maintain since the tests were very raw (i.e., get this select, click it, etc.). The intention of the tests wasn't clear.
Facebook's E2E Automation team in London built a framework around WebDriver, inspired by the concept of WebDriver page objects, and that of React components to make end-to-end tests declarative, stable, maintainable. By declarative, we mean make tests easier to read and write. The test should represent what they're testing, and a person should be able to figure out what the test is doing in a descriptive way. The framework also facilitates stability by inherently dealing with waits and stale elements. You describe what you expect on the screen, and the framework will wait for it.
Finally, through the notion of components, which represent pieces of UI, you can reuse them across pages and tests to assert about their properties or interact with them. So, you essentially never deal directly with web elements and describe your interactions based on this definition.
Видео Readable. Stable. Maintainable. E2E Testing @ Facebook | Archit Pal Singh Sachdeva канала Selenium Conference
Facebook's E2E Automation team in London built a framework around WebDriver, inspired by the concept of WebDriver page objects, and that of React components to make end-to-end tests declarative, stable, maintainable. By declarative, we mean make tests easier to read and write. The test should represent what they're testing, and a person should be able to figure out what the test is doing in a descriptive way. The framework also facilitates stability by inherently dealing with waits and stale elements. You describe what you expect on the screen, and the framework will wait for it.
Finally, through the notion of components, which represent pieces of UI, you can reuse them across pages and tests to assert about their properties or interact with them. So, you essentially never deal directly with web elements and describe your interactions based on this definition.
Видео Readable. Stable. Maintainable. E2E Testing @ Facebook | Archit Pal Singh Sachdeva канала Selenium Conference
Показать
Комментарии отсутствуют
Информация о видео
Другие видео канала
Your Tests Aren’t Flaky, You Are! | Richard BradshawSelenium Hacks | Andrew Krug de MedinaTesting The Way It Should Be (aka Intro Into Cypress)End-to-End Automated Testing in a Microservices Architecture - Emily BacheWrite fewer tests! Model-based testing in React — David KhourshidSystems @Scale 2019 - Continuous Deployment at Facebook ScaleCypress Tutorial - Writing E2E Tests For Your AppsComplete Xpath from Basic to Advance | 14 Xpath Function | All Xpath AXES | Xpath tutorialHow I Cracked Google ? ( Test Automation Engineer )REST APIs and WebDriver: In Perfect Harmony | Mark WinteringhamBuild an automation framework... with a developer mindset | Aditi Mulay | #SeConfLondonModern Web Testing and Automation with Puppeteer (Google I/O ’19)GCP and the Future of Software Testing (Cloud Next '18)Kent C. Dodds – Write tests. Not too many. Mostly integration.Scaling Facebook Live Videos to a Billion UsersTesting In Production, The Netflix WayReact Native EU 2019: Vojtech Novak - Real World e2e Testing With DetoxSelenium 4 (Simon Stewart, UK) [EN]🚀 DevTernity 2017: Ian Cooper - TDD, Where Did It All Go Wrong