---
title: "How Do You Automate End-to-End Tests? The Essential Guide"
description: "End to end testing checks a full user flow across UI, API and database. This guide covers frameworks, environments, CI/CD and what to test first."
canonical: "https://momentic.ai/blog/end-to-end-testing-guide"
last-updated: "2026-10-31T09:55:08Z"
---

# How Do You Automate End-to-End Tests? The Essential Guide

URL: https://momentic.ai/blog/end-to-end-testing-guide

[blog](/blog) [/ resources](/blog/category/resources)  / end-to-end-testing-guide

Resources

How do you automate end-to-end tests? A step-by-step guide covering test frameworks, environments, CI/CD integration, and what to prioritize.

Wei-Wei Wu

CEO, Momentic

End-to-end testing can be one of the most valuable tools in your [testing toolkit](https://momentic.ai/blog/the-software-testing-life-cycle) if you use it correctly.

The right amount of end-to-end testing at the right time provides a super useful 'bigger picture' perspective. It's also great for testing out whether the business logic behind your app is sound, and that everything makes sense from a user point of view.

Rely on end-to-end tests too much, however, and you'll soon find yourself considerably poorer, time and resource-wise, and you'll still be none the wiser about why your code is bugging.

Want to really reap the rewards of end-to-end testing? Read on for everything you need to know about what they are, when to use them, and how to automate them without sinking days into it.

## What is End to End Testing?

End-to-end testing (often snappily abbreviated to 'E2E') is the process of validating your application and its dependencies from start to finish.

In other words, you're testing the interface of your product from a user perspective. Does it do what it is supposed to do without bugs? How easy is it for users to complete specific actions? Do all the elements appear as you think they should?

To do this, you'll need to create an environment identical to the real, post-launch environment that your customers will experience once everything is live. You can use this to test a variety of real-world 'user flows,' for example:

- Logging into a website
- Placing an item in a virtual cart and checking out
- Opening a paid subscription to your app
- Upgrading plans or managing account info

### What are the Advantages of End-to-End Testing?

End-to-end tests are trickier and more time-consuming to run than smaller tests, so why do so many organizations see them as an irreplaceable part of their testing cycle?

Ultimately, it has a lot to do with their ability to give a user-centered, 'bigger picture' view of your application that you won't get by testing the code in smaller chunks. For startups, tech giants, and everyone in between, E2E testing:

- **Offers a genuine user perspective:** some defects only become apparent when looking at the bigger picture. Testing from the perspective of an end user, rather than a developer, is vital for identifying these defects.
- **Validates business logic effectively:** E2E makes sure the workflows and logic that underpin your software work effectively from your user interface.
- **Expands test coverage:** E2E testing ensures your application's dependencies work together, including any third-party code your app might include.
- **Reduces errors found in production:** E2E tests work well as a sort of final check for your app, reducing the risk of bugs slipping through to the production phase.

### What are the Disadvantages of End-to-End Testing?

There are a couple of things to be aware of when planning and executing end-to-end tests, especially if you're doing a lot of them:

- **Slow:** As they are more extensive, E2E tests take a long time to run.
- **Challenging to automate:** E2E testing scripts are complex, which can result in flakiness.
- **Expensive:** It takes a significant amount of resources to set up and maintain an E2E test environment.

Crucially, it's also very difficult to identify the root causes of any issues that crop up in end-to-end tests. If you're testing horizontally (see below), you're not testing individual blocks of code; you're testing the application as a whole. This means that it's vastly trickier to pinpoint what's up and how to fix it.

These disadvantages are minimized if you're smart about what you test, when you test, and how you test it. With the right approach and the right tools, you can save days' worth of time on end-to-end tests whilst maxing out on all the advantages it offers.

Want to know how? Keep reading.

## How do You Automate End-to-End Tests?

Automating end-to-end tests comes down to six steps: identify your critical user flows, choose a framework, build a test environment, write your test scripts, integrate them into CI/CD, and monitor the results. Here's how each step works in practice.

| Step | What You Do | Common Tools |
| --- | --- | --- |
| 1. Identify critical user journeys | List and prioritize the flows that matter most (login, checkout, payment) | N/A, planning exercise |
| 2. Choose your framework | Pick code-first or low-code/AI-native depending on team skill and speed needs | Playwright, Cypress, Selenium, Momentic |
| 3. Build a test environment | Deploy to staging with seeded, predictable test data | Staging servers, test databases, mocks |
| 4. Write test scripts | Script the flow or describe it in plain English | Framework-specific syntax or natural language |
| 5. Integrate into CI/CD | Run tests automatically on every push or PR | GitHub Actions, GitLab CI, Jenkins, CircleCI |
| 6. Generate reports and monitor | Capture screenshots, logs, and traces on failure | Built-in reporting, dashboards |

### 1. Identify Critical User Journeys

Start by listing the flows that matter most: registration, login, search, checkout, payment, and logout are common candidates. Prioritize flows that are used most often, or that are business critical from a revenue or functionality standpoint. Trying to automate everything at once is a fast route to a bloated, unmaintainable suite.

For a SaaS app, the list usually looks like this: sign up, log in, create the core object, invite a teammate, upgrade the plan, cancel. The rule: if the journey breaking would page someone or lose revenue, it gets an end-to-end test.

### 2. Choose Your Automation Framework

Your framework choice depends on your stack and team skill level. Code-first options like Playwright, Cypress, and Selenium give full control but require scripting expertise. Low-code and AI-native tools let you describe a flow in plain English and skip the scripting step entirely, which is worth considering if speed and maintenance are bigger priorities than granular control.

| If you need | Consider |
| --- | --- |
| Cross-browser web tests in code | Playwright |
| A JS-first runner with an interactive UI | Cypress |
| An existing Java or Python WebDriver suite | Selenium |
| Native iOS and Android | Appium or Maestro |
| Tests written as natural-language steps, maintained by AI, for web and mobile | Momentic |

For the longer comparison, see [end-to-end testing tools](/blog/end-to-end-testing-tools).

### 3. Build a Test Environment

Deploy your application to a staging environment that mirrors production as closely as possible. Use test databases seeded with predictable data, and mock third-party services where it makes sense to avoid flaky results caused by systems outside your control.

Use a staging environment with seeded test accounts, reset data between runs, and stub third-party services you do not own: payments in test mode, email to a test inbox.

### 4. Write Your Test Scripts

Whether you're scripting directly or describing flows in natural language, keep tests independent of one another, use stable selectors instead of brittle CSS classes, and avoid hardcoded waits in favor of waiting on actual page or network state.

Here is the same login test two ways. Playwright:

`import { test, expect } from '@playwright/test';  test('user can log in and see the dashboard', async ({ page }) => {  await page.goto('https://app.example.com/login');  await page.getByLabel('Email').fill(process.env.TEST_EMAIL!);  await page.getByLabel('Password').fill(process.env.TEST_PASSWORD!);  await page.getByRole('button', { name: 'Log in' }).click();  await expect(page.getByRole('heading', { name: 'Dashboard' })).toBeVisible(); });`

Momentic:

`# login.test.yaml fileType: momentic/test/v2 id: login url: https://app.example.com/login steps:  - type:  text: "{{ env.TEST_EMAIL }}"  into: Email field  - type:  text: "{{ env.TEST_PASSWORD }}"  into: Password field  - click: Log in  - assert: The dashboard heading is visible`

`type`, `click` and `assert` follow the step syntax in the [Momentic docs](/docs); `{{ env.TEST_EMAIL }}` reads an environment variable.

### 5. Integrate Into CI/CD

Run your E2E suite automatically on every push or pull request, and gate deployments so failing critical tests block a release. Parallelize test execution where you can; this keeps feedback loops fast even as your suite grows.

A GitHub Actions job that runs the suite on every pull request, with the API key stored as a secret:

`name: E2E on: pull_request  jobs:  e2e:  runs-on: ubuntu-latest  steps:  - uses: actions/checkout@v4  - uses: actions/setup-node@v4  with:  node-version: 22  - run: npm ci  - run: npx momentic install-browsers  - run: npx momentic run --upload-results  env:  MOMENTIC_API_KEY: ${{ secrets.MOMENTIC_API_KEY }}`

For Playwright suites, see the [Playwright CI/CD guide](/blog/playwright-ci-cd-guide).

### 6. Generate Reports and Monitor Results

Capture screenshots, videos, and logs on failure so debugging doesn't require rerunning the test manually. Regularly prune flaky tests rather than letting them erode trust in the whole suite.

Track pass rate, flaky rate and run time per suite. Quarantine a test that flakes instead of retrying it forever; see [how to fix flaky tests](/blog/how-to-fix-flaky-tests).

Keep this process in proportion. Automating every possible flow will cost you more in maintenance than it saves in confidence; the goal is coverage of what actually matters, not 100% of your app.

## When to use E2E Testing

To put end-to-end tests in context, let's take a look at a concept devs call the 'testing pyramid.'

You need a lot of the tier along the bottom, and very little of the tier on top. In this case, you need:

- Lots of unit testing (quick tests on individual code units), completed as you go in the main development phase
- A medium amount of integration testing (testing how code components interact with each other to make sure everything is playing nice) throughout the development phase
- A small amount of [end-to-end testing](https://momentic.ai/blog/end-to-end-testing-tools) towards the end of the development cycle, after development has wrapped up

You should only start your end-to-end tests once the development phase is complete and you have tested your code extensively with smaller unit and integration testing.

### What Should You Test in End-to-End Testing?

First things first: testing your entire app will be hugely impractical from a time and expense point of view. Prioritization is key.

What to prioritize? Start with these two categories and make an ordered list:

- Flows that will be most commonly used. If everyone who ever uses your app needs to authenticate their registration via email, that should be a prime candidate to test.
- Business-critical processes that need to work, from a functionality and a commercial point of view. For example, if your checkout process is wonky, it's not just irritating for users; it stops the app generating any revenue.

### Horizontal vs Vertical End-to-End Tests: What to Use When?

Horizontal end-to-end tests focus on complete testing of each stage of a user flow. You verify each step of the process, focusing on the interaction between different parts of the application and checking any state changes that need to take place.

Whilst potentially time-consuming, horizontal tests are simpler to run than vertical. They're a great choice for testing multiple flows; prioritize the flows used most by your customer base.

In a vertical end-to-end test, you test a particular software component at every level of the testing pyramid. You'll perform unit tests and integration tests on a section of code, before verifying the component's behavior when customers interact with it.

Due to their complexity, vertical tests are normally used for a smaller number of business-critical components. What makes this method of testing especially handy is that you can add these tests to a CI/CD pipeline, so you can test your most critical functions on every code commit.

### How many end-to-end tests should you have?

Fewer than unit tests. End-to-end tests are the slowest and most expensive layer, so cover each critical journey once and push detailed cases down to integration and unit tests. See the [software testing pyramid guide](/blog/software-testing-pyramid-guide).

## Natural-language end-to-end tests

A natural-language end-to-end test describes each step in plain English, such as "Click Log in" or "The dashboard heading is visible". In Momentic, the steps are stored as YAML files in your repository, reviewed in pull requests like other code, and run from the CLI with `npx momentic run`. Element locations are resolved when the test runs, so a renamed class or a moved button does not need a selector update.

What that changes in practice:

- Assertions are written in plain English instead of code.
- The same test runs locally, against any URL, and in CI.
- Tests keep passing when the markup changes, because each step describes the element instead of a selector.

## Running end-to-end tests with Momentic

> "Momentic makes it 3x faster for our team to write and maintain end-to-end tests."

We'd love to see if [Momentic](https://momentic.ai/)'s AI testing could help you optimize your software testing life cycle.

If, like Alex and his team, you're keen to save over two-thirds of the time you spend on key testing processes, why not [schedule a conversation with our team](https://momentic.ai/sales)?

## Frequently asked questions

How do you automate end-to-end tests?    Identify your critical user journeys, choose a framework, build a staging test environment, write your scripts, integrate them into CI/CD, then monitor results and prune flaky tests over time.    What's the difference between automating E2E tests and manual E2E testing?    Manual testing has a human perform the flow directly; automation runs scripts (or AI-driven natural language tests) that simulate the same actions without human input on every run.    What tools are commonly used to automate end-to-end tests?    Code-first frameworks like Playwright, Cypress, and Selenium are popular for teams that want full scripting control, while low-code and AI-native tools let you describe flows in plain English instead.    Should all my tests be end-to-end tests?    No. Most of your suite should be unit tests, a smaller portion integration tests, and only a small number of E2E tests covering your most critical, highest-value user flows.    How do I keep automated E2E tests from becoming flaky?    Use stable selectors instead of brittle CSS classes, avoid hardcoded waits in favor of waiting on real page or network state, keep tests independent of shared state, and regularly prune tests that fail inconsistently.    How do small teams automate tests?    Small teams can automate tests by prioritizing critical user flows, using low-code or AI-native tools, and integrating automated tests into CI/CD to save time and reduce maintenance.    What is the difference between end-to-end and integration testing?    Integration tests check that two or more components work together, often without a browser. End-to-end tests drive the real app the way a user does, from the UI through to the database.    How long should an end-to-end suite take?    Under 15 minutes on a pull request, with the tests run in parallel. Run the complete suite nightly if it takes longer.

Still have additional questions?

## Keep reading.

[Resources   How to move tests out of testRigor, mabl or Katalon into your repo     Check testRigor, mabl and Katalon export options, preserve test coverage and migrate bounded flows into Playwright, Cypress or Momentic.     Wei-Wei Wu     7 min read](/blog/migrate-testrigor-mabl-katalon-tests-to-repo)[Resources   How to turn Jira and Linear tickets into end-to-end tests and bug reports automatically     Use Jira and Linear context to scope Mo testing, review findings, file Linear issues and create regression tests with documented integrations.     Wei-Wei Wu     7 min read](/blog/jira-tickets-to-end-to-end-tests)[Resources   How to test a Lovable, Replit or Bolt app before you ship it     Test a Lovable, Replit, Bolt or Claude Code app before release with code checks, browser regressions, authorization tests and CI gates.     Wei-Wei Wu     7 min read](/blog/test-lovable-replit-app-before-deploy)

## Try Mo on your app.

Mo is an AI QA engineer. It tests your running app and files each bug with repro steps. Free to start, no credit card.

[Try for free](https://app.momentic.ai/signup) [Contact sales](/sales)