All software companies strive to produce quality products. The journey begins with a product that works. is usually defined as the adherence of software to its specification. In most cases, formal verification is not possible. As such, we typically . Software correctness impose functional correctness with test coverage To rise to the challenge, companies cultivate a culture that of all stacks to . This culture usually gives birth to an abundance of static, unit, and integration tests written by developers. However, . encourages developers write tests of varying scope many companies do not offer their developers the tools to write end-to-end (E2E) tests In a world of distributed systems of growing complexity, ? is that enough Motivation . We’ve all faced the harsh reality of a seemingly perfectly covered new feature crashing and burning over a pesky inter-service bug. Isolated component tests are likely to fail to spot critical bugs Wouldn’t the world be a better place if to verify the ? In many companies, these tests are the domain of software automation engineers. Traditionally, they're written on dedicated frameworks such as . developers could write a few E2E tests users get the experience we want to deliver Selenium As such, they're largely . For front-end engineers, they are sometimes written in a different programming language. This . unfamiliar to the developers artificial boundary restricts developers from making the most out of automated testing The of are clear: advantages developer-driven E2E testing — Supplementing the developers' toolbox with E2E tests encourages and improves the adoption of , with its numerous . Having these tests as part of the main task rather than an appendix assures the feature is truly covered before release. Higher product quality and maintainability Test-Driven Development benefits — Owning the feature’s entire lifecycle fosters responsibility for the quality of the finished product and boosts the developers’ perceived impact. Reliance on external testing (whether automated or manual) reduces developer accountability. This poses the risk of a shallow sense of ownership and a “not my problem” mentality. An atmosphere of ownership — Endorsing a holistic approach to testing by assigning the entire testing or to developers hastens development. Firstly, it removes the overhead of involving an additional party in the development process. Secondly, it prevents pipeline-lengthening test redundancy. After all, there is no need to burden the build pipeline with an E2E test where an existing lean integration test suffices. Faster development pyramid trophy — To add to the previous point, fewer tests (especially hefty Selenium suites) demand fewer resources to execute. Operating cost reduction The Solution . Empower with light and simple to start testing their products. Make E2E tests a common commodity developers tools and methodologies The Road to Success ? I won’t repeat the many trade-offs that come with any of the existing E2E testing frameworks. The subject is out of the scope of this story and has been covered (e.g. and ). Instead, I’ll share the gist of my process: What tools extensively Selenium vs. Puppeteer TestCafe vs. Cypress After working with Selenium, I felt it was not a suitable solution. The bulkiness of the WebDriver and its limited mocking capabilities render it impractical for TDD, and the framework’s learning curve was too steep for a ubiquitous instrument. In the same corner lies the newer framework, with which I had experience in browser automation. Unfortunately, along with the recently-released , it suffers many of the same pain points. Puppeteer Playwright The framework, while ticking off many boxes, uses a test paradigm that may not feel natural for front-end developers who are used to the common testing frameworks. TestCafe Some of the gaps in these frameworks can be filled by , which is a versatile wrapper. Yet, its limited popularity makes it a tougher commitment in an enterprise setting CodeceptJS Eventually, I settled on a POC for . Cypress ? In their own : Why Cypress words Our mission is to build a thriving, open source ecosystem that , , and generates . We hold ourselves accountable to champion a . enhances productivity makes testing an enjoyable experience developer happiness testing process that actually works First and foremost, I felt Cypress is a . After all, enjoyability makes or breaks the adoption of new tools and ideas. If we are to reap the fruits of developer-driven E2E testing, . choice for developer happiness developers should want to write tests Secondly, I saw great potential in Cypress’s to facilitate some of my product’s unique testing requirements. Thirdly, its popularity and community support make it a . extensibility safer choice for the future With the proper wrapping and extension, . As developers code, a simple terminal command can launch an impressive that executes tests on a real browser. Cypress helps developers integrate testing into their everyday workflow test runner The same test runner, in the same run environment, can then be used in the . The results are presented in beautiful that may include screenshots, recordings of test runs, and anything else you’d like to attach. CI pipeline of your choice reports When it comes down to it, ? what does Cypress offer — It’s . Quick enough to test our code continuously. Upfront, this is due to Cypress being the only framework mentioned that runs in the browser. However, one of its chief performance boosts is derived from the and back-end mocking capabilities. Blazing speed quick built-in extended In E2E tests, why waste precious seconds waiting for buttons to be clickable when you can replay a recorded page startup? In more limited test scopes, why should you wait for the server to execute a complicated query when an appropriate JSON response suffices? — New tools always involve a learning curve. Out of the box, Cypress utilizes the ubiquitous , , and test stack. If that isn’t your cup of tea, you might enjoy some of the exciting plug-in support, including , , and even . Easy to adopt and use Mocha Chai Sinon Jest-style assertions React Testing Library Gherkin syntax — Cypress is not limited to E2E testing. It can support tests of all scopes. Beyond the innate scoping determined by modifying the extent of back-end mocking, there are specialized . Holistic approach plug-ins for component testing Readable error messages and stack traces, access to developer tools, test recording and snapshotting, all mount up to a simple experience that is less likely to leave you wondering why your test failed. Debugging simplicity — debugging — Developers can run the same tests they used during development right in the CI pipeline. Cypress offers to most providers. Official are available to run Cypress locally and in CI. Integration ready examples Docker images — Cypress is a popular project with enterprise backing and significant community support. The ecosystem already includes many ranging from authentication to framework extensions. This extensibility extends to you — it’s relatively easy to with the existing API. Little stops you from fitting Cypress to your needs. Extensibility plug-ins write your plug-in To successfully , one might need to undergo a process of customization to make it in the context of their product and development procedures. integrate Cypress into the workflow as accessible as possible Accessibility may translate to minimal setup, comfortable and familiar configuration, ready-to-use commands, support for the preferred test stack syntax, performance tuning, and CI integration. Conclusion As I see it, on R&D and organizations as a whole. empowering software developers with E2E testing can have a far-reaching impact It’s important to note that , but . This approach drives , promotes an , leads to , and . E2E tests don’t replace component test coverage unlock a holistic testing scheme higher product quality and maintainability atmosphere of ownership faster development reduces operating costs For instance, developers working on a component should complement the unit-tests with an E2E test that checks its functionality from a user’s standpoint. Towards that end, I find that . Backed by blazing speed and ease of use, it has the potential to to adopt this approach. Coupled with Cypress’s impressive extensibility, . Cypress is geared towards developer-driven testing keep developers happy and motivated anyone is free to fit it to their needs I’d like to stress that E2E developer-driven testing (e.g., software automation engineers). Testing by external parties has its benefits, mainly rooted in the desire to avoid letting the fox guard the henhouse. does not necessarily come at the expense of automation by external parties
