Understand What to Automate
UI tests are the most expensive tests to write and the slowest to run. Before recording anything, decide which flows deserve one. This is the same thinking as understanding requirements for a performance test: the tool comes after the plan.
Why This Matters
A UI test suite that tries to cover everything ends up slow, flaky and ignored. A small suite of the flows that matter, kept green, is what actually catches regressions. Aim for the second one.
Questions to Ask
What are the critical user journeys?
List the flows that would be a production incident if they broke. Typical examples:
- Login and logout
- The main "do the job" flow (place an order, submit a claim, create a record)
- Search and open a record
- Payment or checkout
- Anything with a signature, approval or legal step
Write them down as a numbered list with the steps a real user takes. This list becomes your test names later.
What already has coverage lower down?
| Level | What it checks | Speed |
|---|---|---|
| Unit tests | One function or component | Milliseconds |
| API tests | One endpoint, request and response | Milliseconds to seconds |
| UI tests (Playwright) | The whole stack through a real browser | Seconds per test |
If a rule is already tested at the API level, the UI test only needs to check that the screen shows the result, not re-test every rule. Validation messages, edge cases and error codes are usually cheaper to cover at the API level.
What is stable?
Screens that change every sprint make bad UI test targets. Automate a flow once its UI has settled, or accept that you will be updating locators often. Section 5 shows how to choose locators that survive most redesigns.
What do you control?
- Test data. Each test should create or own the data it needs, or run against a seeded environment that resets. A test that depends on "the record someone created last week" will break.
- Test accounts. One account per role (admin, normal user, read-only). Never a real person's account.
- The environment. Test against staging or a dedicated test environment, not production. Third-party sites, payment gateways and email providers are mocked or stubbed, not driven for real.
What is the pass condition?
For each flow, name the one thing that proves it worked. "The order confirmation page shows the order number" is a test. "Click through checkout" is not.
Decide the Scope
Fill in a table like this before you touch the recorder:
| # | Flow | Steps | Pass condition | Data needed | Role |
|---|---|---|---|---|---|
| 1 | Login | Open site, enter credentials, submit | Products page is shown | standard user | user |
| 2 | Add to cart | From products, add one item | Cart badge shows 1 | none | user |
| 3 | Locked out user | Login with locked account | Error message shown | locked user | user |
This is exactly the table the sample project implements. Keep the first version short. Five good tests that run on every pull request beat fifty that nobody trusts.
What Not to Automate in the UI
- Third-party pages you do not own (social login screens, payment provider pages). Stub them.
- Visual polish. Pixel comparisons are possible but fragile. Start without them.
- Every validation message on every field. Cover one happy path and one failure per form, push the rest down to API or unit tests.
- Flows that need a real email or SMS. Use a test inbox service or a stub.
Tips
-
Name flows the way the business says them. "Submit leave request" not "click button 3". These names end up in reports that non-testers read.
-
One flow, one test. Do not chain login, search, edit and delete into one long test. When it fails you will not know which part broke.
-
Write the pass condition first. If you cannot say what the screen should show at the end, you are not ready to automate it.