Sample questions
Mobile Testing AutomationDifficulty 2
In the mobile test pyramid, why do unit tests make up the largest share of the suite?
- aThey are the only tests that run on a device
- bFast and isolated, so feedback is quick✓
- cThey verify UI rendering automatically
- dThey need no update when the UI changes
Explanation:Unit tests exercise small, isolated logic without a UI or device, so they run in milliseconds and rarely break for unrelated reasons. That speed and stability is why the pyramid puts many of them at the base.
Mobile Testing AutomationDifficulty 2
Why are full UI (end-to-end) tests generally more expensive and fragile than unit tests?
- aThey cannot be automated at all
- bThey only check compile-time types
- cWhole stack runs, more can break✓
- dThey can only ever test one screen
Explanation:A UI test drives the real app through rendering, animations, navigation, and often network or device state. Every one of those layers is a potential source of failure and added runtime, which makes UI tests slower and more likely to break for unrelated reasons.
Mobile Testing AutomationDifficulty 1
What is an integration test, positioned between unit and UI tests in the pyramid?
- aA few real parts working together, no full UI✓
- bA single pure function checked in isolation
- cOnly runs on a CI server, never locally
- dReplaces the need for manual QA
Explanation:Integration tests sit in the middle: they combine a handful of real collaborating units (like a view-model talking to a repository) to check the seams between them, but avoid driving the actual rendered UI, keeping them faster and more stable than full UI tests.
Mobile Testing AutomationDifficulty 2
A UI test taps a button right after load, but the tap handler wires up only after an animation ends. The test intermittently fails. Most likely cause?
- aThe framework cannot tap buttons
- bThe screen has a memory leak
- cThe test raced the animation, not readiness✓
- dThe button has the wrong color
Explanation:Animations and other async UI transitions introduce timing variance. If the test taps blindly without confirming the screen (and its handlers) are actually ready, it will sometimes race ahead of the app and fail — a classic flaky-test root cause.
Mobile Testing AutomationDifficulty 2
What does it mean to mock a network dependency in a mobile test?
- aDisable the test whenever there is no network
- bSwap the real call for a fake response✓
- cRun the test twice to average out latency
- dBake the server's real response into the binary
Explanation:Mocking a network dependency means substituting the real call with a stand-in that returns a predetermined response (success, error, empty, slow, etc.). This removes reliance on an external server's availability and lets the test control exactly what scenario it exercises.
Mobile Testing AutomationDifficulty 3
A profile-fetch test hits the real backend. When the backend is slow, unrelated tests start failing too. Best fix?
- aMock the network layer for that test✓
- bDelete the failing tests
- cRaise the timeout to 10 minutes
- dOnly run the suite at night
Explanation:The root problem is a hard dependency on a live, external system inside a test that is meant to check the app's own logic. Mocking the network call isolates the test from backend availability and turns an unreliable external dependency into a controlled, repeatable input.