As a front-end developer, I’ve learned that building a web application means paying close attention to how everything works for the user, from the underlying code to the smallest interaction. Bugs can show up in the most unexpected places, and without proper testing, they can easily make their way into production. That’s why end-to-end (E2E) tests are such an important part of my workflow.
In this article, I’ll share why E2E tests are so valuable, how I’ve implemented them in a real-world project, and some lessons I’ve learned along the way. Whether you’re new to testing or looking to improve your current setup, I hope this gives you some useful insights.
Before diving into testing, let me talk a bit about Vue.js. It’s my go-to framework for front-end development because it’s simple, flexible, and gets the job done without unnecessary complexity. The reactivity system makes it easy to build dynamic interfaces, and the component-based structure keeps everything organized and maintainable. Whether I’m working on small features or large-scale applications, Vue.js always feels like the right tool for the job.
The project: A smarter way to connect businesses and job seekers
The project I’m working on is a B2B job distribution platform that helps businesses connect with job seekers more efficiently. It allows companies to create job ads, manage advertising campaigns, and distribute them across multiple publishers like Indeed and LinkedIn. The platform is designed to optimize ad performance and make the hiring process smoother for everyone involved.
With so many features and integrations, ensuring everything works as expected is a big challenge. That’s where E2E tests come in - they help us catch issues early and keep the platform running smoothly.
Why E2E tests are so important
E2E tests simulate real user interactions, testing the entire flow of an application from start to finish. Unlike unit tests, which focus on individual components, or integration tests, which check how components work together, E2E tests validate that everything works as a whole. They’re especially useful for catching issues that only show up when different parts of the system interact.
For our platform, we’ve written over 200 E2E tests to cover all the critical functionalities, from user registration and project creation to advertising campaigns and external service integrations. It’s a lot of work, but it’s worth it for the confidence it gives us in our releases.
Our E2E testing setup
We use Cypress for our E2E tests, and I highly recommend it. It’s easy to set up, has a clean API, and runs tests directly in the browser, which makes debugging much easier. That said, every project is different, so I encourage you to explore other tools like Playwright or Selenium to find the one that fits your needs best.
Our tests run daily in the CI/CD pipeline, early in the morning. I’ve made it a habit to check the results first thing every day before diving into other tasks. Running the tests daily works well for us because of the complexity and number of our flows. Resetting the development database is necessary to avoid data mismatches or overload from previously created data. While we could run the tests after every pull request merge, this setup strikes the right balance for our workflow.
How E2E tests help us every day
E2E tests have become an essential part of our development process. They’ve helped us catch countless small issues before they made it to production, saving us from potential headaches down the line. For example, we’ve found bugs in user registration flows, campaign creation, and even in interactions with external services. These might seem minor, but fixing them early makes a big difference in the overall user experience.
A recent example: major changes to campaign types
One of the most significant times E2E tests saved us was during a recent update to our advertising campaign module. Previously, we had four different campaign types for major publishers like Indeed and LinkedIn, each with its own requirements. To simplify things, we decided to merge them into a single campaign type, allowing us to advertise the same job ads across multiple publishers using an internal algorithm.
This was a huge change that involved removing the old logic and replacing it with new code. Everything seemed fine until we decided to launch the new campaign type for a small group of customers first. This meant reverting some of the old logic and combining it with the new code to support both the old and new campaign types.
As you can imagine, this introduced a lot of complexity, and we missed some important edge cases. Thankfully, our E2E tests caught these issues before we deployed to production. We were able to fix the problems, ensure that both the old and new functionalities worked as expected, and roll out the changes smoothly. The deployment went off without a hitch, and both our users and stakeholders were happy.
Lessons learned
Here are a few things I’ve learned about E2E testing that might help you:
- Start with the Basics: Focus on the most critical user flows first, like registration or payments. You can always add more tests later.
- Keep Tests Organized: Use clear naming conventions and structure your test files logically. This makes it easier to maintain them over time.
- Run Tests Regularly: Integrate your tests into your CI/CD pipeline and run them daily or before major releases. This helps catch issues early.
- Don’t Overdo It: E2E tests are powerful, but they’re not a replacement for unit or integration tests. Use them to validate high-level flows, not every edge case.
Final thoughts
E2E tests might seem like a lot of work, but they’re an investment that pays off. They give you confidence in your code, help you catch critical issues, and make deployments smoother. If you’re not already using E2E tests, I highly recommend starting small and building up from there.
Testing helps you make things better with every iteration. Start now and your future self will be glad you did.