A travel booking app's search screen UI tests call every API against the real server, so they're slow and break often. How would you split what stays a UI test from what moves down to unit or integration tests?
Keep two or three core flows that a user really walks, from search to a completed booking, move details like sort rules and error message mapping down to unit tests, and replace the UI tests' responses with stub data passed in through launch arguments.
TestingShort answerIntro
What's the difference between unit tests, integration tests, and UI tests?
#ui-test
TestingShort answerBasics
What is a test double?
#stub
TestingShort answerBasics
This screen leans heavily on an API response. How would you change the code so you can…
#stub
TestingShort answerAdvanced
You have dozens of UI tests that are slow and break often. How would you restructure the…
#ui-test