What a login test should protect
- The user can enter credentials and submit the form
- The application authenticates correctly and does not return an error
- The user lands on the expected post-login state — a dashboard, account page, or known heading
- The flow works end-to-end across the real auth stack, not just in isolation
Why login tests become brittle
Login forms look simple but they are surprisingly fragile targets for automation. Small product changes cause repeated breakage: a button renamed from 'Log in' to 'Sign in', an email field whose label changes, an SSO redirect added to the flow, a new loading state between credential submission and the dashboard render.
Tests written against the raw DOM structure break every time one of these changes lands. Tests written against stable product-level concepts — button labels, field names, expected post-login state — are far more resilient.
Keeping login scenarios maintainable
The scenario below is intentionally simple. It describes what the user does, in order, and what they expect to see at the end. When any part of the login flow changes, the update to this scenario is a readable, reviewable one-line change — not a hunt through selector code.
URL: https://app.example.com/login SCENARIO: User can log in PROCESS: - Fill "email" with "qa@example.com" - Fill "password" with "hunter2" - Click "Sign in" EXPECT: Dashboard
FAQ
Should login tests use real user credentials?
Use a dedicated test user rather than a real account. A test user gives you a stable, isolated login state that does not depend on production data, is not affected by real account changes, and can be reset if something goes wrong during a test run.
What should the expectation be after login?
Use a meaningful, stable post-login state — a dashboard heading, a known page title, or a specific navigation element that only appears when authenticated. Avoid expectations tied to dynamic content like notification counts or recent activity that can change between runs.
What happens when the login flow changes — for example, SSO is added?
Update the scenario to reflect the new flow. If SSO is added, the scenario changes to reflect the new redirect step. The Assert execution layer regenerates from the updated scenario. The change is a readable diff that goes through normal code review.
Put the workflow in your repo, not in a chat transcript
Assert is strongest when scenarios become durable project assets: readable Markdown in the repo, generated execution underneath, and result inspection in the dashboard.