Training Notes: Testing in Android — Part 1
Introduction
Hello😃,
I presented an internal training about Android app testing. I wrote down couple notes to support the presentation. These notes include all information about testing fundamentals and unit testing. This article will be about going over these things quickly. Now that I’ve explained what this article is about, here we go.
Schedule
1. Why do we need to write tests?
2. How can we define tests?
3. Where to write tests?
4. Test doubles
5. Unit tests
6. Given-When-Then
Content
1. Why do we need to write tests?
- To check if our code is working correctly
- To see our errors as soon as possible
- To see errors before releasing to users
- To save time(Yes, you read it right. The bigger the app gets, the harder manual testing completes. So writing tests helps us save time in the long term.)
2. How can we define what to test?
a) Subject
- Functional testing: does my app do what it’s supposed to?
- Performance testing: does it do it quickly and efficiently?
- Accessibility testing: does it work well with accessibility services?
- Compatibility testing: does it work well on every device and API level?
b) Where to run?
- Instrumented tests run on an Android device, either physical or emulated. The app is built and installed alongside a test app that injects commands and reads the state. Instrumented tests are usually UI tests, launching an app and then interacting with it.
- Local tests execute on your development machine or a server, so they’re also called host-side tests. They’re usually small and fast, isolating the subject under test from the rest of the app.
c) Strategy
- FIDELITY — REAL OR EMULATED DEVICE
- SPEED
- RELIABILITY
It’s a matter of time. If you want to release an app quickly, you need speed but if your aim is more consistency, you need to write more tests to make your app more reliable.
Keep that in mind: Testable Architecture is an important subject to save you time. The projects with clean architecture, help you to save time, better readability, and maintainability.
d) Scope
- Unit tests or small tests only verify a tiny portion of the app, such as a method or class.
- Medium tests are in between and check the integration between two or more units.
- End-to-end tests or big tests verify more significant parts of the app at the same time, such as a whole screen or user flow.
3. Where to write tests?
It’s simple. If your tests require a device, it’s in androidTest. If not, test.
4. Test Doubles
a) Fake:
Provides information to the client with simple and quick responses.
b) Mock
Provides specific information to the clients.
c) Stub
Used to return pre-defined responses.
d) Dummy
Only used as arguments. Don’t have a real impact.
e) Spy
Just like a mock with more complex and detailed state handling.
f) Shadow
- Only used for robolectric
- Replaces classes that can not execute on a development machine
- When the class instantiated in the test, robolectric looks for its shadow class
- Always need a public no-arg constructor
5. Unit tests
- No physical or emulated device needed
- Uses JVM
- Aims small section of code
- Placed in module-name/src/test/
- Use testImplementation to apply dependencies
- JUnit4, Mockito, Mockk, and Robolectric common libraries
- Assertion libraries: junit.Assert, Hamcrest, Truth
6. Given-When-Then
It’s a best practice when you write tests. Given, define the variables. When, call the function that you wanted to test. Then, check if your function works correctly.
Conclusion
In this article, we mentioned about fundamentals of testing quickly and saw examples of how we use them. Like coding, writing tests is about practicing pretty much and theoric part is a small amount of it. What I mean, after reading this article, it is all up to you. Part 2 will be about integration and UI tests.
Good day, see you in the next articles :)
