MA9: Testing, signing and store release
Testing a mobile app
🎯You'll be able to
Choose what to test automatically and what to test on real phones, and write down honestly what has and hasn't been tested.
🏠The everyday picture
A bakery checks each batch with a thermometer and a timer, and the baker tastes one loaf before the shop opens. The tools catch most problems quickly; the tasting catches what tools miss.
📘What it really is
- Unit tests check small pieces of logic: validation, merging, the backoff delay. They run in seconds on any computer.
-
Component tests render screens in a test renderer and press buttons, as KhetNote's
tests/screens.test.jsdoes with React Native Testing Library. -
End-to-end tests drive the real app on a simulator or phone with tools such as Maestro or Detox. They're slower and need more setup, so teams keep them for the main journeys.
-
Device testing by hand: low-cost Android phones, a small screen, a large font, the screen reader, dark mode, weak signal.
- Honest records: a release note says "Automated tests: pass (28 of 28)" and "Android and iPhone devices: not verified" until someone actually tries them.
📝A worked example
Input: KhetNote 1.1.0 is ready for testing.
Steps:
- Run
npm testand record the result: 28 of 28 pass on Linux. - List the device checks from
docs/device-testing.md: a 2 GB Android phone, TalkBack, VoiceOver, airplane mode, large text. - Mark each device check "not verified" until it's done, and note who did it and on which phone when it is.
Expected output: a "Tested on" section that says exactly what was checked.
🌍Where it's used
- Banking apps run component tests on every change and end-to-end tests on sign-in and payments.
- Delivery apps keep a shelf of older, cheaper phones for testing by hand.
- Small teams use automated tests for logic and a short device checklist before each release.
📝Case scenario
A clinic app passed all its automated tests, and the team released it. On older phones with a large font setting, the "Save" button was pushed off the screen. A five-minute device check with a large font would have caught it, so the team added it to the checklist.
🖱️Try it
Read KhetNote's docs/device-testing.md. Pick three checks you could do on a phone you have, and write how you'd record each result.
Success: each check has a pass, a fail or "not verified", with the phone named.
⚠️Common mistakes
- Only testing on a fast phone. Sign: complaints from users with cheaper phones. Fix: test on a low-cost Android phone too.
- Writing "tested" without saying how. Sign: nobody knows what was checked. Fix: name the tests, the phones and the results.
- End-to-end tests for everything. Sign: slow, flaky test runs. Fix: unit and component tests for most checks.
🛠️For your project
Project 3's test 7 checks the release notes have a "Tested on" section that says "pass" or "not verified".
✅Quick check
Why keep most checks as unit and component tests?
Show the answer
They're fast and reliable, so they can run on every change.
What should a release note say about devices nobody has tried yet?
Show the answer
That they're not verified.