First of all, small apps made from scratch are usually tested manually using either a virtual emulator in high-end systems or using an android phone externally for low-end systems as the emulator may cause lagging or freezing of the system in low-end devices.
The more features present in the app you built, the harder it is to test the app manually. So, performing automated tests ensure that the app is working correctly before publishing.
Now, Automated testing can be classified into few categories :
- A unit Test
- An integration test
- A widget test
Based on facts, it is advised that there are trade-offs between different types of test which I am going to show in the table below :
Unit Widget Integration Confidence Low Higher Highest Maintainance Cost Low Higher Highest Dependencies Few More Most Execution Speed Quick Quick Slow
Let’s get a brief explanation of different types of tests:
Unit Test :
A unit test as the name suggests tests single methods, functions, or even class. The sole aim of the unit test is to verify the correctness of a unit of logic under several conditions. The unit test usually doesn’t write on disk, or read from disk, or read user instruction from outside the process which is running the test. The external dependencies of the unit under test are generally mocked out.
Integration Test :
The Integration test performs a test on the larger section of the app or even tests the complete app as per requirement. The main aim of this test is to verify whether all the widgets or services that are tested are working together perfectly as expected or not. Also, the app’s performance can also be tested using this app.
The app under test is typically isolated from the test driver code to avoid skewing the results. This test usually runs on a real device or virtual emulators such as an Android simulator or iOS simulator.
Continuous Integration services :
Continuous Integration services allow you to run tests automatically whenever a change in code is detected. This provides timely feedback on whether the changes in code work as expected and does not introduce any bugs.
Widget Test :
In some cases, the widget test is also called a component test. The aim of this test is to vary the looks and design of the UI and the interaction with the user as expected. Testing of widgets involves testing multiple classes.
For example, the widget being tested should be able to interact with users and responds to user commands, perform layouts, and initiate the working of the child widgets. A widget test is therefore more comprehensive than a unit test. However, like a unit test, a widget test’s environment is replaced with an implementation that is much easier and much simpler than a full-blown UI system.