We had, and still have, the following goal: to provide a way to write consistent, debuggable, maintainable, and valuable e2e (end-to-end) automation tests for our front-end applications and integrate with cicd (continuous integration and continuous deployment). To reach the state we have today where perhaps hundreds of e2e tests are triggered or run on a schedule across all of our sendgrid front-end teams, we had to research and experiment with many potential solutions along the way. Until we have accomplished this main goal. We attempted to launch our own custom ruby selenium solution developed by dedicated test engineers called sitetestui aka
Stui where all teams could contribute to a repository and run cross-browser automation tests. It unfortunately succumbed to slow and choppy company mailing list testing, false alarms, a lack of context between repositories and languages, too many hands in the same basket, painful debugging experiences, and more time spent on maintenance than added value. We then experimented with another promising library in webdriverio for writing tests in javascript collocated with each team's application repositories. While this solved some issues, strengthened team ownership, and allowed us to integrate tests
With buildkite, our cicd vendor, we still had flaky tests that were painful to debug and difficult to write in addition to processing. Too similar selenium bugs and quirks. . We wanted to avoid another stui 2.0 and started exploring other options. If you want to read more about our lessons learned and strategies discovered while migrating from stui to webdriverio, check out part 1 of the blog post series. In this final part of the blog post series, we'll cover our journey from stui and webdriverio to cypress and how we went through similar migrations in setting up the overall infrastructure, writing curated e2e tests, integration with our buildkite pipelines and scaling for other front-end teams in the organization.