What is it?
If it is too small, the effort is too high. If it is too big, it is difficult to test.
Right! It is the unit.
But what actually makes a good unit definition? And why is it important at all?
The definition of a unit has a lot of influence on the test process, but at the same time it is imprecise. If the unit is defined in an unfavorable way, this can mean a lot of effort or even trouble. Definitions of the term unit are found in ISO 26262, ISTQB, Automotive SPICE and many others.
And our conclusion is: A unit is a small testable software component. Unfortunately, very fuzzy. Not for tooling, but for assessments and audits. So, in most organizations the term is specified individually.
There are two approaches to the definition of the term unit: a generic description and an architectural description.
In a generic description, a unit would be defined as a file or a function. From a specific, architectural point of view, a unit would be an element in the software architecture. A specific definition based on the architecture can reduce the number of test objects in unit testing. A unit defined this way can include multiple functions in multiple files.
This approach does not violate the requirements of ISO 26262 or Automotive SPICE. Furthermore, if the architecture has been developed top-down, you can designate higher levels of your architecture as pure integration testing and thus also save test objects at unit test level. The tests thus omitted at unit level are then performed in software integration testing (SWE.5).
Some organizations close the gap with their own requirements by adapting the definition of a unit. Typical additions include:
– define units more precisely, e.g. by defining units as an encapsulation of data and instructions at the level of a function in the programming language C, or
– requirements for the unit construction process, e.g. by specifying the maximum cyclomatic complexity.
Pro-tip: Well-intentioned requirements that are too general or too strict for a concrete project, can be discussed and negotiated with the client to define a coherent solution as a substitute measure. This can significantly reduce efforts. From a risk perspective, the right time defining units is as early as possible.
By the way, in TPT you can test all kinds of unit definitions. From the tool’s point of view, it doesn’t matter. In order to reduce the resulting total effort in the testing process to a minimum, we recommend not to define units generically. This facilitates refactoring activities and reduces additional efforts.
Learn more about unit testing before your competitors do. You can contact us here.
Related topics
