Something that is often talked about, perhaps above all linked to test automation, is unit and integration tests. But what do these tests mean in practice and how are they used? You’ll find out in this blog post!
Unit tests test the smallest units in an application, so we know they work as intended. These tests are strongly related to the actual implementation, rather than verifying whether a system works as intended from an operational perspective. In test-driven development, unit tests are used to define how a unit should be formulated and verify given input parameters and output conditions to produce correct results. Instead of writing production code first and unit tests after, unit tests are written first which of course neither work to run nor show correct results. Based on that situation, the production code is allowed to grow by creating what is needed for the unit test to succeed. Unit testing should be seen as an important supplement during development, rather than a type of test sufficient to verify proper quality.
Integration testing tests that all units in an application work together. In these tests, the application can be called from the outside as it is intended to be used by the user or other systems. This means they are not connected to the solution in the same way as unit tests, and thereby do not need to be affected to the same extent, and the solution, for example, be refactored. Integration tests are perfect for regression testing and can be built to find bugs as early as possible. To highlight the testability of the application for these tests is a prerequisite. How to authenticate against an application to be integration tested, and what about application configuration if the service is to be tested locally on a work computer?
Let’s make a simple analogy:
An internal device in an application can be compared to a part under the hood of your car, such as the fan belt. To ensure the quality of the fan belt, it will be tested separately, where things like strength, life and friction in the material are checked. However, it is not important for the driver that there is a fan belt in the car, but rather that the car is robust, and thus needs a functioning cooling of the engine. If the car manufacturer were to develop an entirely new method of cooling the engine, the internal tests to test fan belts would be useless, but the tests of the car would be unchanged from a driver’s perspective. One could use the same driver-based tests to judge that the car drives as well or better with the updated cooling.
Even though the purpose of unit and integration testing is different, they can often be built using the same techniques. By their very nature, unit tests need to be written in the same programming language as the code being tested to be most effective. This helps us find compilation errors due to updates, making feedback as fast as possible. These tests have rarely or few dependencies to infrastructure, and are thereby freed from challenges around test environments, test data and dependencies to other systems. Something that makes unit tests the most reliable test type.
By using the right tools, you can in many cases get the same good benefits for integration testing. You will need prerequisites to call the application from the outside and through, where the right client support and mocking technology need to be used. It is also common that you need to execute the entire application as intended to access the entire tech stack.
Unit testing and Integration testing are two important prerequisites for developing software with the right quality. Together, they form the earliest automatic tests that are absolute prerequisites for being able to deliver new software at a high frequency in a short time. By choosing the right tool, you will gain a high level of confidence in these tests. They will provide support for new development and a justified sense of quality for changes.