How do you choose which tests go at the UI, API and unit levels?
60-second answer
I follow the test pyramid. Business logic and calculations, like discount rules or validation, are best covered by fast unit tests, usually written by developers. Service behaviour, contracts, data validation, error handling and permissions go to API tests, which are fast and stable. UI tests cover only critical end-to-end user journeys and things that genuinely need the browser, like rendering, navigation and client-side behaviour. If a UI test is checking twenty combinations of a calculation, those should move down to API or unit level.
Explanation
Typical split: ~70% unit, ~20% API/integration, ~10% UI (the exact ratio depends on the system).
Questions to decide the level:
- Is the logic in the frontend or backend?
- Does it need a real browser to be meaningful?
- How often will it run, and how fast must feedback be?
- What's the cheapest level that would catch this bug?
Anti-pattern: the "ice-cream cone", mostly slow UI tests and few unit tests.
Example
Coupon rules: 40 combinations tested via API in 20 seconds. UI tests: just two, one coupon applied and shown in the cart and one error message displayed.
Sample code
/\ UI / E2E ~10% critical journeys
/ \
/----\ API / integration ~20% contracts, rules, auth
/ \
/--------\ Unit ~70% logic, calculations