Subscribe or follow on X for updates when new posts go live.
If you have spent any real amount of time in QA or web development, you have probably felt the tension between tests that feel useful and tests that exist mostly to satisfy a coverage number or a dashboard. I have watched teams build impressive looking automation suites that light up green every day while real users quietly run into broken flows, confusing UI states, or dead-end forms. I have also seen the opposite happen, where a small, focused set of tests caught issues early and gave developers confidence to ship faster.
This article is written from that lived experience. My focus is web applications and websites, where the UI is the product and the browser is the runtime. The patterns below are shaped by years of seeing what helps QA engineers, developers, and product managers align around quality, and what tends to waste time or create brittle systems that break more often than the product itself.
I am also in the middle of building an application that rethinks how automated testing should be authored and maintained. That effort has forced me to be very honest about what kinds of tests actually prove something about the product, and which ones mostly prove that a selector still exists.
There are two broad groups of approaches discussed here. The first group contains patterns I strongly prefer because they are battle tested, readable, and tied closely to user-visible behavior. The second group includes approaches I recommend avoiding or using very sparingly because they are fragile, expensive to maintain, and often validate internal implementation details that users never see.
Throughout the article I will compare and contrast these two groups, using examples and Cypress test suites that should feel familiar to anyone who has worked in modern web QA.
At the very bottom of the testing pyramid for web applications is a deceptively simple question: does the app load and render at all. This is not glamorous work, but it is foundational. Page and smoke assertions catch catastrophic failures that make everything else irrelevant, such as JavaScript runtime errors, broken bundles, missing routes, or misconfigured deployments.
These tests typically assert that the page loads without crashing, that a few critical UI elements exist, and that the correct route or layout is active. They are not trying to validate business logic or deep interaction flows. Their value is in fast feedback and broad coverage.
A good smoke test does not over-specify the UI. It avoids brittle selectors and instead looks for elements that represent the existence of the application itself, such as a root container, a navigation bar, or a known page heading.
Here is an example Cypress suite that demonstrates this approach:
describe('Application smoke test', () => {
it('loads the home page without crashing', () => {
cy.visit('/')
cy.get('body').should('be.visible')
cy.get('[data-testid="app-root"]').should('exist')
})
it('renders the main navigation', () => {
cy.get('nav').within(() => {
cy.contains('Home')
cy.contains('Account')
})
})
it('lands on the expected route', () => {
cy.location('pathname').should('eq', '/')
})
})
These tests tend to be stable over time because they are aligned with the structural contract of the app. When they fail, the failure is usually meaningful and worth stopping a deployment for.
Once you know the app loads, the next useful layer is asserting that the UI is in the correct state. Web applications are state machines wrapped in HTML and CSS. Buttons enable and disable, modals open and close, spinners appear and disappear. Users experience these transitions constantly, even if they do not consciously think about them.
Visibility and state assertions focus on these moments. They answer questions like whether a submit button is disabled before a form is valid, whether a loading indicator shows during a request, or whether a modal actually closes when the user dismisses it.
The key here is that the assertions are driven by observable state, not implementation details. You are not asserting that a specific React hook fired or that a Redux action dispatched. You are asserting that the UI reflects the state the user expects to see.
Example:
describe('Login form UI states', () => {
beforeEach(() => {
cy.visit('/login')
})
it('disables submit until required fields are filled', () => {
cy.get('button[type="submit"]').should('be.disabled')
cy.get('input[name="email"]').type('user@example.com')
cy.get('input[name="password"]').type('password123')
cy.get('button[type="submit"]').should('be.enabled')
})
it('shows and hides loading indicator on submit', () => {
cy.get('input[name="email"]').type('user@example.com')
cy.get('input[name="password"]').type('password123')
cy.get('button[type="submit"]').click()
cy.get('[data-testid="loading"]').should('be.visible')
cy.get('[data-testid="loading"]').should('not.exist')
})
})
These tests age well because they are anchored to user-perceived behavior. If the UI state changes, that usually reflects a real product change, not a refactor.
This is where automated tests start to feel like a user actually using the product. User interaction assertions verify that clicking, typing, selecting, and navigating produce the expected UI changes. They answer questions such as whether clicking a button reveals new content, whether submitting a form navigates to the next step, or whether a menu opens when hovered or tapped.
The strength of these tests is that they model intent. They do not care how the code is structured internally. They care about cause and effect as the user experiences it.
A common mistake here is to chain too many interactions into a single test. A better approach is to keep each test focused on one meaningful outcome.
Example:
describe('User interaction flows', () => {
it('opens the settings panel when clicking the settings button', () => {
cy.visit('/dashboard')
cy.get('[data-testid="settings-button"]').click()
cy.get('[data-testid="settings-panel"]').should('be.visible')
})
it('navigates to profile page from dashboard', () => {
cy.get('[data-testid="profile-link"]').click()
cy.location('pathname').should('eq', '/profile')
cy.contains('Your Profile').should('be.visible')
})
})
These tests are especially valuable to developers because they protect core user flows. When they break, it is often because a real interaction changed or regressed.
Content is often overlooked in automated tests, but it is one of the most important aspects of a web application. Users rely on text to understand what happened, what went wrong, and what to do next. Content and text assertions verify that the right information is shown at the right time.
This includes success messages, error messages, and user-specific data. The goal is not to assert every word on the page, but to assert the presence of meaningful signals.
For example, when a form submits successfully, the user should see confirmation. When something fails, the user should see an actionable error.
describe('User feedback messaging', () => {
it('shows success message after saving settings', () => {
cy.visit('/settings')
cy.get('input[name="displayName"]').clear().type('New Name')
cy.contains('Save').click()
cy.contains('Settings saved successfully').should('be.visible')
})
it('shows error message on failed login', () => {
cy.visit('/login')
cy.get('input[name="email"]').type('wrong@example.com')
cy.get('input[name="password"]').type('wrongpass')
cy.contains('Sign in').click()
cy.contains('Invalid email or password').should('be.visible')
})
})
These assertions are deeply tied to user experience and are often appreciated by product managers reviewing test coverage.
Forms are where many web applications either shine or frustrate users. Validation behavior is especially important because it guides users toward successful completion. Form validation assertions verify required fields, inline error messages, and prevented submissions when data is invalid.
Good tests here assert both the presence and the timing of validation feedback. They also avoid asserting implementation details like specific validation libraries.
describe('Registration form validation', () => {
beforeEach(() => {
cy.visit('/register')
})
it('prevents submission with missing required fields', () => {
cy.contains('Create account').click()
cy.contains('Email is required').should('be.visible')
cy.contains('Password is required').should('be.visible')
})
it('shows inline validation for invalid email', () => {
cy.get('input[name="email"]').type('not-an-email')
cy.get('input[name="email"]').blur()
cy.contains('Enter a valid email address').should('be.visible')
})
})
These tests tend to be stable because validation rules change less frequently than UI layout.
Navigation is the backbone of a web app. If routing breaks, users get lost quickly. Navigation and routing assertions verify that links go where they should and that protected routes behave correctly.
These tests should be simple and direct. They are not trying to assert the entire page content, only that navigation succeeds and lands the user in the expected place.
describe('Navigation behavior', () => {
it('navigates to help page from footer link', () => {
cy.visit('/')
cy.get('footer').contains('Help').click()
cy.location('pathname').should('eq', '/help')
cy.contains('How can we help').should('be.visible')
})
})
Authorization bugs are some of the most serious issues a web application can have. These tests verify that users can see only what they should and cannot access restricted areas.
The focus should be on UI visibility and access, not on the internal auth mechanism. For example, asserting that an admin link is hidden from regular users is far more valuable than asserting a specific token structure.
describe('Authorization and permissions', () => {
it('hides admin controls from regular users', () => {
cy.loginAs('user')
cy.visit('/dashboard')
cy.get('[data-testid="admin-panel"]').should('not.exist')
})
it('blocks access to admin route for non-admin users', () => {
cy.loginAs('user')
cy.visit('/admin')
cy.contains('Access denied').should('be.visible')
})
})
No application is perfect, and failures will happen. What matters is how the app fails. Error handling tests verify that the app fails gracefully, communicates clearly, and does not leave the UI in a broken state.
These tests often simulate error conditions through user actions rather than forcing internal failures.
describe('Graceful error handling', () => {
it('shows fallback UI when page fails to load data', () => {
cy.visit('/reports')
cy.contains('Unable to load reports').should('be.visible')
cy.contains('Try again').should('be.visible')
})
})
Visual testing is useful when applied carefully. Lightweight visual assertions focus on major layout breaks rather than pixel-perfect comparisons. For example, asserting that a header exists or that a critical section is visible is often enough.
The goal is to catch obvious visual regressions without creating brittle tests that fail on every minor CSS change.
describe('Basic layout checks', () => {
it('renders main header and content area', () => {
cy.visit('/')
cy.get('header').should('be.visible')
cy.get('main').should('be.visible')
})
})
One of the most common traps in UI automation is asserting network behavior directly. Tests that expect a specific request to fire or validate exact XHR payloads are tightly coupled to implementation details. They often break during refactors that do not change user behavior at all.
If your goal is to test APIs, do that at the API layer. UI tests should care about what the user sees and can do, not which endpoint was called behind the scenes.
Another brittle pattern is asserting exact data values rendered from the backend. For example, checking that a list has exactly ten rows or that a specific ID appears in a table. These tests tend to fail whenever seed data changes or environments drift.
A better approach is to assert that data renders at all and that the UI responds correctly to its presence, such as showing empty states or pagination controls.
Strong QA automation patterns are not about writing more tests. They are about writing tests that prove something meaningful about the product. Tests should act as a safety net, not as a second implementation of the app’s internal logic.
When tests are aligned with user-visible behavior, they tend to survive refactors, framework upgrades, and team changes. They also build trust with developers and product managers because failures usually reflect real issues.
As tools and platforms evolve, the principles remain the same. Focus on what users experience, keep tests readable, and resist the urge to over-assert internal details. That discipline is what separates automation that adds value from automation that simply exists.