Mocking, in Android Instrumentation tests
Some tests fail when there is a bug, some tests fail when they are the bug. If this resonates with you, read on!
A test is considered useful, and of value, if it catches regressions. Automating it makes the test very deterministic and trustworthy, something you will love and the developers will trust their life with. On the other hand, tests can quickly become non-deterministic or flaky.
The reasons for flakiness of a test can be varied:
- Tests <> Application Under Test(AUT) synchronisation.
- Service to service call SLA breaches in lower environments
- Test data not in pristine condition
- Test environment is not in a production like a state
- AUT is ready, but dependent services are not
- Too much orchestration in test flow to reach desired validation state
- Third-party environment dependencies and many others…
Tests in your Continuous Integration (CI) environment, that fail ‘sometimes’ add a degree of confusion and ultimately a rejection of their acceptance as trustworthy and reliable software. Imagine if your car didn’t start at every ignition you attempted — even after repair. You would probably stop using and ultimately sell the car to a more patient person — wouldn’t you?
Why would software engineering be any different — tests which don’t provide the required value are quickly forgotten and usually ignored. The answer likely rests in a stage of testing where you can effectively ‘isolate’ your application under test from all the peripheral dependencies, data reliability, and environment behaving themselves. The answer lies in mocking your problems away — and there are side benefits of unlocking blaze speed tests as well :)!
Let me show you the “Pyramid of Testing” then, as majestic as the ones in Egypt but probably cited more than the real pyramids in our industry.
Why Mock?
Test what you care about: A mocking framework ensures that your tests are fast, self-contained, and deterministic.
De-couple teams to work at their own speed: Mocking will eliminate the need for real service being available for you during testing.
Be negative without breaking everyone’s joy: With mocking, you can test negative user journeys or error handling by simulating errors. You can do this without touching your environment or putting the application into states which would disturb your colleagues’ test environment.
Blazi-ness: It will speed up the testing not only by isolating failures but also by eradicating the slow network calls.
How to Mock?
We will use Wiremock for mocking the server-side dependencies.
- Add Wiremock dependencies in gradle for android Test
2. Integrate wire mock in tests
WireMock has JUnit rules to manage the server’s lifecycle and setup/tear-down tasks. To start and stop the WireMock per-test case, add the following rule to your test class.
Note: Ensure that port 8080 is not used anywhere
3. Intercept the request and change the URL to localhost
Create an Interceptor to intercept HTTPS traffic and change the URL to localhost http://127.0.0.1:8080.
Add interceptor to your Network module
4. Mock the response
a. Error response: Response with a status code 400 to be returned when the URL matches /mocked/url and request type is GET .The body of the response will be jsonBody with error data
b. Empty response body: Response with a status code 429 to be returned when the URL matches /mocked/url and request type is POST with an empty response body
c. Success response: Response with a status code 200 to be returned when the URL matches /mocked/url and request type is PUT
removeStub to delete the stub mapping after each test run. Add it as part of teardown in your test class.
5. Tests with mocked response
a. Test will check for the error message on the UI when status code is 400 with error data in JSON body
b. Test will check success on the UI when the status code is 200
tearDown to delete the stub mapping after each test
Try this and deliver smiles to your team! Of course, do be careful of what you mock and how you do it — you don’t want to end up with false positives by building an over-engineered mock response. Keep it simple, keep it real as much as possible and you should be fine.
Want to work on problems like these? We’re hiring! We’re fully remote! Check out open roles at https://tech.hotstar.com .
