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
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.