Classically speaking, unit testing in IT is a topic that is at home in software development. However, to make it easier to understand, it can also be compared with the procedure used in general manufacturing processes.
If you look at the production of a car, for example, it is not just a matter of drawing up a list of parts, assembling everything and checking after completion whether it has really become a functional car. When manufacturing a car, it is probably relatively vivid and clear to everyone that there are many components whose functions can and are tested individually. The required properties and parameters of each part are defined and can therefore be checked long before they find their way into a vehicle.
Software development can be viewed in a very similar way. There is software that is to be created and has to fulfill certain properties. The final properties are generally broken down, the overall complex of the software is divided into many small "components" or units. Each of these units can be described by certain properties, i.e. each unit has a certain signature, consisting of parameters that go in from the outside and results that come out at the end.
What is the goal of unit testing?
The approach and aim of unit testing is to use the expertise from design and development directly during the implementation of the individual units and to derive test cases from this. The idea behind this is that those involved in the design know exactly which requirements the individual unit has to fulfill. However, they regard the unit as a kind of black box. The developer, on the other hand, knows the code and can therefore refine the test a little if necessary, as he knows every single branch that arises in the implementation.
The aim of the defined test cases is to ensure that as many "paths through the code" as possible are covered by a test case. It is not always possible to achieve 100% coverage, as this sometimes also depends on how finely granular the individual units to be tested are defined.
It is not uncommon in unit testing that - depending on the framework used - writing the tests quickly takes as much time and effort as writing the actual code.
How are unit tests implemented?
Unit tests are sensibly developed in parallel by the developers, whereby the (rough) test cases can already be defined in the design in some cases. The tests can be implemented at different levels of granularity. The deeper you go into the code, the higher the coverage that can realistically be achieved with the test cases. The higher the level chosen, the more difficult it is to cover all variants. If detailed changes are made later, it may be more difficult to recognize whether the new conditions are already covered by the tests or not.
For traditional software development, there are corresponding frameworks that enable the code to be run through the associated tests quickly and easily in parallel with implementation. At the latest, however, when the artifacts are checked into a repository or in nightly automated runs, where the code is checked against the tests and corresponding logs are generated.
You can find out how unit testing can be used in PowerCenter in the PDF!
