When it’s better not to unit test your apps
By DeviQA on Tue Dec 13 2016 00:00:00 GMT+0000 (Coordinated Universal Time)
We all lack something to start automated testing. Some of you may lack time or money. Indeed, often the ratio of the quality of work and time spent is enough to start conducting auto-tests.
Basic Functionality of (Unit Testing) iOS Applications
Unit tests are dealing with the code. Ideally, you take each method, create a test, supply various settings and check the result correctness. For example, a relatively easy way to test the function of multiplication.Conversely, to test the method that starts the animation is hard. In the development of iOS-applications it often turns out that 80% of the application it’s the UI, which doesn’t have a clear technical task and there’s very little time for creation. In such circumstances, it’s hard to write tests.
What you can check with unit testing:
- Convert units to make sure that one meter is always equal to one hundred centimeters.
- Priority of units showcase, so that the Latin «c» will be for Celsius rather than the speed of light.
- Formatting units display. To make large/small numbers display with degrees, and the currency with suffixes. To make sure that thousands are separated by spaces, and the time is displayed correctly.
- Group item lists in the menu, the sequence of menu items.
- String parsing from the clipboard.
The main difficulty is to learn how to switch the locale without restarting the simulator. Some tests require different locale for different languages.
When you should Avoid Unit Testing iOS Apps
Software testing is a combinatorial problem. For example, each possible value of the boolean will require two tests: one TRUE option, the other - FALSE option. As a result, each line of source code will require 3-5 lines of test code.
As with any technology testing, unit testing does not allow programs to catch all errors. In fact, it follows from the practical impossibility of tracing all possible paths of the program, except for the simplest cases.
The result is known only approximately
For example, mathematical modeling. Business applications often work with finite and countable sets, scientific - with continual. It’s so difficult to find tests for each of the branches of the program, it is difficult to say whether the result accuracy is maintained correctly, and so on. But in many cases the quality of the simulation is determined approximately, and the latest result is recorded as a reference. If you find a discrepancy, the new result is checked by hand and you find out what is more qualitative: old or new.
Errors in integration and performance
Each of the modules is tested separately. This means that the integration errors at system-level are not determined. Furthermore, this technology is useless for performance testing. Thus, unit testing is more efficient when it is used in conjunction with other testing methods.
Absence of tests monitoring
To obtain the benefits of unit testing, it’s required to strictly follow the testing technology all along the software development process. It is necessary not only to keep a record of all tests, but also about all the changes of the source code for all modules. For this purpose, you should use source control software.
Thus, if a later version of software does not pass the test, which was successfully performed earlier, it is easy to check the versions of the source code and fix the bug. It is also necessary to ensure constant monitoring and analysis of the failed tests. Failure to do so will result in an increase of failed test results.
Problems with mock objects
Test object must interact with other objects except for some minor cases. These mock objects are made extremely simple: either highly simplified (memory instead of the database), or designed for specific test and mechanically repeating the exchange of the session. Questions arise when the communication protocol is changed; it is necessary to look for the mock in all the tests and change for the new protocol.
What you should Avoid when Testing iOS apps
Integration with the environment (network, database, file system)
This option is probably the most controversial among all. You can find examples of using TDD with tasks such as the development of a calculator. It is clear that these problems have nothing to do with reality. When developers come back into the project, they do not know how to apply their knowledge and skills into their daily work.
The simplest cases that are similar to the calculator are covered by unit tests, and the rest of the functionality is developed as usual. As a result, there’s no understanding why you should waste time on unit tests if the code is so straightforward and complex code is still not covered.
In fact, there is nothing super wrong if you use the database or the file system in your unit tests. At least you can be sure in the performance of the function, which is the core of the system. The question is only how to use the external environment in the most effective way to keep a balance between tests isolation and the speed of their implementation.