When would you write an API test instead of a UI test?
What the interviewer wants to hear
- API tests are faster, more stable and cheaper to maintain
- Good for business logic, validations and data combinations
- UI tests for critical user journeys and UI behaviour
- API calls can also set up data for UI tests
Model answer
I write an API test whenever the behaviour I care about lives in the backend: validation rules, calculations, permissions, error codes and data combinations. API tests skip the browser, so they run in milliseconds instead of seconds and break less often, since they do not depend on layout or timing. For example, checking 30 discount rules is far better done through the API. I use UI tests for what only the UI can show: critical user journeys like signup to purchase, that elements display and respond correctly, and integration of frontend with backend. I keep the UI layer small, following the test pyramid. I also combine both: a UI test can create its user and data through the API first, then only test the screen it is about, which makes it faster and more reliable.
Can you answer it under time pressure?
Take a timed easy round and get scored on every answer.
More easy Automation Test Engineer questions
- Why do teams automate tests, and what should not be automated?
- Explain the Page Object Model and its benefits. Are there any downsides?
- What is the difference between implicit waits, explicit waits and auto-waiting?
- How do you run automated tests in a CI pipeline?
- How do you choose locators for UI tests, and what makes a locator fragile?
- Explain the test pyramid. How does it guide what you automate?
- When you automate tests for a REST API endpoint, what do you check?
- What makes an automated test good?
- Compare Selenium and Playwright. When would you choose each?