Research guide
Login Test Cases: 30+ Functional, Negative & Security Scenarios
A practical E2E test case list for login flows: valid and invalid credentials, rate limiting, session persistence, logout, route protection, and the browser journey that proves the gate works.
What a login test should prove
Login is the gate to every protected action, so the test has to prove more than a button navigating. It should prove the sign-in itself, the session it creates, what happens on logout, and which routes stay protected.
Split the checklist into the sign-in moment and the aftermath: session persistence, token refresh, multi-tab behavior, and route guards.
Happy-path test cases
Valid credentials: the customer is authenticated, redirected into the app, and the auth form disappears.
Session persistence: reloading the page keeps the session, opening a new tab keeps it, and a protected route opened directly while signed in loads without another login.
Negative and validation test cases
Wrong password: a clear error, and the customer stays on the login page. Non-existent email: an error that does not reveal whether the address has an account.
Empty fields: validation errors before submit. Malformed email: rejected with a format message. Excessive failed attempts: rate limited with a retry state instead of an endless loop.
Locked, disabled, or unverified accounts: the error state the customer actually sees is part of the coverage, not an edge case to skip.
Session and logout test cases
Logout clears the session and redirects; a refresh after logout does not restore it; other open tabs eventually reflect the logged-out state.
An expired access token auto-refreshes without dropping the page, and concurrent refreshes from two tabs do not error out.
Route protection test cases
Visiting a protected route while signed out redirects to sign in and returns the customer to the intended destination after login.
Role-restricted pages show an access-denied state for the wrong role instead of leaking content.
Where coded tests stop being enough
Login is stable enough for coded assertions in most apps. Add browser-journey coverage when the login UI is A/B tested, redesigned often, or sits in front of SSO, OAuth, and social sign-in, because that is where copy, layout, and provider flows change fastest.
With CueTest you describe the login journey in natural language, such as “sign in with the test account and verify the dashboard opens,” and the agent adapts to the current interface while leaving screenshots and a trace for review.
Key takeaways
- Login tests must cover the sign-in, the session it creates, logout, and protected routes, not just the form.
- Negative cases, such as rate limiting, locked accounts, and unknown email, are where auth products actually fail.
- Keep auth invariants deterministic and add a browser journey for login surfaces that change frequently.