Gains:
- Ability to produce unit, integration and UI tests with artificial intelligence in accordance with the testing pyramid and cover limit and error situations as well as happy scenarios
- Ability to weed out empty/useless tests and bloated coverage by checking that each test generated actually validates a behavior
- Ensuring the test catches the bug and prevents it from fixing the bug by telling the AI what the code should do
Writing code is half the job; Proving that code works correctly is the other half. Mobile apps encounter hundreds of different devices, screen sizes, operating system versions, and user behaviors. It is impossible to test all of these manually; That's why automated testing (code testing code — testing that runs without a human click) is the backbone of mobile quality. AI is incredibly efficient at writing tests because writing tests is exactly the kind of pattern work it likes: validating a specific behavior for specific inputs. In this unit, we will learn how to accelerate unit testing, interface testing and automation with AI, but ensure the quality of the test through human eyes.
Testing pyramid: what to test and how much
A healthy testing strategy resembles a pyramid. The base includes a large number of unit tests (quick testing that tests a single function or class in isolation); they are fast and cheap. In the middle is less integration testing (testing how multiple parts work together). At the top there is minimal UI/end-to-end testing (testing done by clicking on the screen as the user does); they are realistic but slow and fragile. AI helps at every layer, but the most value is at the base: quickly producing unit tests of business logic.
Test type
Scope
speed
AI efficiency
unit testing
Single function/class
very fast
very high
integration
interlayer
medium
high
UI / end-to-end
All screen stream
slow
Medium (fragile)
Tip: When telling the AI to "generate tests for this function", explicitly ask for edge cases: empty input, null, negative number, very large value, network error. AI produces happy path easily; The real mistakes hide in the borders and jump out if you don't want them there.
Steps of writing tests with AI
- Define the behavior to be tested. "This function should give this output to this input."
- Specify the framework. JUnit + MockK on Android, XCTest on iOS, Espresso (Android) or XCUITest (iOS) for UI.
- Ask for limit states. Happy scenario + error + breakpoints.
- Manage mock objects. External dependencies such as network and database are emulated for testing (mock — controlled mock instead of the actual service).
- Run the test and verify. Does the test pass, does it confirm anything truly meaningful?
The fifth step is critical. AI sometimes produces useless tests that “always pass”; for example, a test that does not verify anything or checks its own fake data. A passing test and a valuable test are different things.
Caution: Just because the AI can produce does not mean the test is correct. Sometimes the AI accepts the current (perhaps faulty) behavior of the code as "correct" and writes tests accordingly. Such testing fixes the bug rather than catching it. You determine what the test expects; Tell the AI what it should do, not what the code does.
Test coverage measure and fallacy
Test coverage (what percentage of code is run by tests) is a useful but misleading metric. 90% coverage indicates that 90% of the code has been executed; but it has not been verified that those lines are working correctly. A test that runs a line and does not check the result inflates the scope but does not provide security. The goal is not high numbers, but meaningful validation. You can quickly scale up with AI, but make sure each test actually tests a behavior.
three mini cases
Case 1 — Border situation caught. AI was asked for tests for a money transfer function in a banking application, and specifically "negative amount" and "more than balance" scenarios were added. The test revealed that the transfer was not blocked with a negative amount; this would be a major security vulnerability in production. Closed by adding a one line control. Lesson: boundary tests are the most valuable tests.
Case 2 — Fake test. One team was relieved to increase coverage to 85% with 40 unit tests produced by AI. During inspection, it was seen that most of the tests did not actually verify any output, they just called the function and wrote assertTrue(true). Coverage was high but protection was zero. Tests were overhauled and rewritten with real validations. Lesson: coverage numbers can lie.
Case 3 — UI testing accelerated. An e-commerce team wrote an XCUITest script of the add-to-cart flow with AI in 20 minutes; If it were written by hand, it would take half a day. AI guessed screen element identifiers; The team matched them with the real code and fixed them. Draft speed is real, but identifier verification is human work.
Weak prompt / Strong prompt
Weak prompt: "Write a test for this function."
Powerful prompt: "Produce unit tests for this Kotlin function with JUnit5 + MockK. Function: money transfer (amount, source, target). Behaviors to test (what the code should DO):- Valid transfer must be successful- Negative or zero amount must be rejected- Amount greater than the balance must be rejected- Network error must throw appropriate exception Each test should verify only one thing, their names should be descriptive, mock the external service. Do not write an empty assertion."
Copiable templates
Unit test template: "Generate [JUnit/XCTest] unit tests for this function for [language]. Expected behavior: [what to do]. Include: happy scenario, null input, breakpoints, error case. Let each test verify single behavior; use meaningful assertion; mock. [code]"
UI testing template: "Write a UI test of the following flow with [Espresso/XCUITest]: [user flow step by step]. Select screen elements with accessibility id, use id instead of text. Add wait strategy. Remind me to match element ids to actual code."
Test audit template:"Examine these tests:1) Do they actually verify an output/behavior or are they null?2) Do they cover limit cases?3) Do they bug fix the code or expect correct behavior?Flag and strengthen weak tests. [tests]"
Coverage optimization template: "Identify untested parts of this class and suggest meaningful tests. Prioritize paths with real risk, not just the number of coverages. [code]"
Common mistakes
- Just testing the happy scenario. Errors are stored in limit states; Ask for them openly.
- Accepting an empty/useless test. Tests of the assertTrue(true) type inflate the scope and provide no protection.
- Having the AI verify what the code is doing. Testing should expect what the code should do; otherwise it fixes the bug.
- Mistaking the scope number for the purpose. 90% coverage does not mean 90% accuracy.
- Linking to text in UI testing. The test is broken when the text changes; Use stable identifier (id).
- Setting up mocks incorrectly. The "unit test" that calls the actual service will be slow and brittle.
In summary
Testing is the backbone of mobile quality, and AI is very efficient in this area, especially in unit testing. Follow the testing pyramid: many units, medium integration, little UI testing. Explicitly ask the AI for the happy scenario as well as limit cases and error paths. Make sure that each test generated actually validates a behavior; Empty tests and inflated coverage are misleading. Most importantly, tell the AI what the code should do, not what it does, so the test catches the bug, not fixes it.
Application task
Request tests from the AI using the “Unit test template” for a business logic function (e.g. discount calculation or form validation) and explicitly specify limit cases (null, negative, too large). Run the generated tests, then have the same tests audited with the "Test audit template". Find at least one weak test, strengthen it, and test whether the tests catch an actual error of the function (by adding a small bug).
checklist
- [ ] I selected the appropriate layer for the test pyramid (priority unit)
- [ ] I wanted limit and error cases besides the happy scenario
- [ ] I verified that each test contains a meaningful assertion
- [ ] I told the AI what the code should do, not what it does
- [ ] I focused on the actual risk paths, not the number of coverages
- [ ] I used stable identifier in UI tests, I did not bind to text