Dear community, I often distinguish between two roles when programming. They help me to take a certain view and improve my design.
One role is that of the producer. The synonym here would be the term provider. The other role is consumer or user.
Ideally, the provider’s offer matches the consumer’s demand, at least to a large extent. The search for the optimal value here is well known from other disciplines such as market research in marketing.
The importance of match
The match between supply and demand is very important.
During programming, it means for me (the consumer) that I can implement a certain requirement with an existing development object (provider).
But what is even more important for me after years of working as a developer: How quickly can I find out whether the respective development object will help me?
How often have I spent hours of laborious work analyzing a BAPI, a class, a CDS view or other development objects? BAPIs in particular have cost me a lot of nerves. Especially when they do not adhere to the BAPI standards at all.
Unit Tests and their impact on design
When developing classes and interfaces, it is a good idea to switch from the provider role to the consumer role using unit tests. This means you are the first consumer of the class you have just developed (including the interface). This increases the chance of achieving a good match. For yourself, but also for everyone else.
The importance of this step cannot be overestimated for many reasons. In this blog I look at the effects on the chosen design.
Simple object instantiation
One or more objects are created from a class. This is the consumer’s first contact with what the provider makes available. Suitable unit tests quickly show whether object creation is simple or complicated.
For example, the constructor could have optional parameters. What looked like a great solution when developing the class is simply impractical for the consumer. When does he set which parameter and what result can he expect? So you might change your design to include several static constructor methods (factory methods), whose names are meaningful to the consumer.
Simple object usage
An object is created once and then used many times within the scope of its available methods. If you try out this use in practice using unit tests in the consumer role, the following design aspects are put to the test, among others:
- Are the method names comprehensible?
- Does the object have an internal state (see immutable objects)? If it has a state: what is it like before and after the object is used?
- What information does the object reveal from its state to the outside world and in what way (e.g. public read-only attributes or getter methods)? Can the internal state be changed?
- Does the object need an initialization sequence before it can be used correctly (setter sequence)? How is this sequence clear to the consumer?
- Are all of the object’s dependencies resolved, for example through dependency injection? What requirements must be met for an isolated test?
- How does the object behave in the event of an error?
- How does the object behave when used successfully?
- How does the object behave when used in series?
Summary
Unit tests allow us to try out our chosen class design and, if necessary, adapt it long before it is used by other consumers and the associated restrictions to maintain compatibility. This is one of the many benefits that unit tests offer. This is exactly why you should use them. More benefits of unit tests will follow in other blogs – promise.
Have fun trying out
Michael