Began to mature in our web applications, we wanted to add another level of testing on top of our usual unit and integration testing layer. We looked to build new pages and features with e2e (end-to-end) test coverage with browser automation tools. We wanted to automate testing from the customer's perspective and avoid manual regression testing as much as possible for any significant changes that may occur to any part of the stack. We had, and still have, the following goal: to provide a way to write consistent, debuggable, Maintainable, and valuable e2e automation tests for our front-end applications and integrate them with cicd (continuous integration and continuous company mailing list deployment). We experimented with several technical approaches until we finalized our ideal solution for e2e testing. On a high level, this sums up our journey:build our own custom internal ruby selenium solution, sitetestui aka stui transition from stui to node-based webdriverio not being happy with either setup and eventually migrating to cypress this blog post is one of two parts documenting and highlighting our experiences, lessons learned, and tradeoffs with each of the approaches used along the way to hopefully guide you and other developers, on how to connect e2e testing with useful testing patterns and strategies. The first part encompasses our early struggles with stui, how we migrated to webdriverio, and yet we still experienced many stui-like downfalls. We'll see how we wrote tests with webdriverio, dockerized the tests to run them in a container, and finally integrated the tests with buildkite, our cicd provider. If you want to take where we are with e2e testing today, please move on to part two as we complete our final migration from stui and webdriverio to cypress and how we have it configured in different teams. Tldr: we encountered similar issues and difficulties with the two selenium encapsulation solutions, stui and webdriverio, that we eventually started researching alternatives in cypress.