Demystifying Unit Testing in Business Domains

Unit Testing

What is a unit test? The general definition of a unit test is that it is the process of testing the smallest unit of code. In object-oriented programming, the smallest unit of code is a public method of a class.

Unit Testing vs Integration Testing

Can we then say with certainty that by writing code that tests a public method of a class, we are creating a unit test? Unfortunately, no, because the method we are testing may or may not use the functionality of another class. And that's the whole point, because if the functionality of another class is not used, then we are creating a unit test, otherwise we are creating an integration test.

Integration Testing

The general definition of an integration test is that it is the process of testing how multiple parts of a software system work together as a single unit. Don't be misled when you hear the words "single unit" at the end of the definition of an integration test. In this case, we are talking about a "single unit" assembled from various other units that should already have been tested using unit tests.

Now let's interpret the clause "multiple parts of a software system" in the definition of an integration test. What is the smallest granularity we can get, going as deep as possible into the structure of which the software is built? The answer is one class. That is, at the maximum level of granularity, we can say that an integration test is the process of checking how multiple classes work together as a single unit.

So, what's the verdict? Can we say that if the method we're testing uses the functionality of another class, then we're writing an integration test instead of a unit test? In other words, is it even possible to write a unit test in this case? To answer these questions, we need to consider the meaning of the term "another class."

Considering Class Affiliation

There are several options for the source of which another class can be a part.

Programming Environment Class

The first and most common source of another class is the underlying programming environment, such as the .Net Framework. Should we question the correctness of the programming environment? No, we shouldn't, otherwise we wouldn't be able to produce any software at all. So, when the method we're testing uses the functionality of another class that belongs to the programming environment, we're still writing a unit test.

Non-functional Architecture Class

The second source of another class is the non-functional architecture or infrastructure intended to support the programming functionality of the business domain. Often, when developing a software product, a set of classes is created that are not related to the business functionality of the application itself but provide various services. Examples of such services are logging,  authorization, etc. Should we be concerned about the case where the method we are testing uses the functionality of another class that belongs to a non-functional architecture? Generally, we should not, because the functionality of a non-functional architecture is widely used throughout the application, and in many cases such a non-functional structure is intended to serve most applications created by the same software developer.

The keyword "generally " means that the object belonging to the non-functional architecture was not created inside the method for which we are writing a unit test but was provided to it as an argument. If this is not the case, the method code must be refactored to exclude the creation of an instance of a component belonging to the non-functional architecture inside a class belonging to the functional architecture. The creation of an instance of a component belonging to the non-functional architecture inside a method of a component belonging to the functional architecture should be completely prohibited.

After refactoring the method, we can remove the "generally" keyword from our statement and say that we are still writing a unit test when the method we are testing uses the functionality of another class that belongs to the non-functional layer of the application.

There are two exceptions, however.

The first exception occurs if we are testing a method belonging to a data access component that is designed to work directly with a data store. For such a component, only integration tests can be written, since the nature of the component is to integrate a data source into the application.

The second exception occurs when the method we are testing uses a communication component that communicates with another part of the application over a network, if the application is a distributed system deployed on multiple computers. In this case, only integration tests can be written for the method we are testing, since its nature is to connect multiple parts of the system into a single whole during application execution.

Functional Architecture Class

The third source of another class is the business domain or functional architecture. Consider the following example where the parent object uses the functionality of the child object:

Do we write a unit test or an integration test for a method belonging to the class "Parent" if the method uses the functionality of the class "Child"? The answer to this question depends on whether the parent object knows what the child object is or not. But why does the parent object need to know what the child object is? The answer is simple – to create it:

As soon as the method we are testing instantiates an object of another type, our test method becomes an integration test rather than a unit test, because the method integrates another part of the system into itself, even if that other part is represented by its smallest part, which is a class.

For our test to remain unit-based and not turn into an integration test, we need to remove the knowledge from the parent object about what the child object is. But how can the parent object use the child object without knowing its functionality? The answer is simple - there must be a contract between the parent object and the child object, according to which the parent object expects the child object to provide some services, and the child object agrees to service the parent object's requests according to this contract:

In this case, the parent object (service consumer) has no knowledge of the child object (service provider). The contract (interface) is between them and satisfies the behavior of both parties involved. An interface is a service agreement between two unrelated classes, a service provider and a service consumer, that specifies the expectations of the service consumer and the commitment of the service provider to deliver its services in accordance with those expectations. That is, the consumer of services does not really care who the service provider is, the main thing is that he receives the required service in accordance with his expectations.

The question arises: how can a parent object use a child object without creating an instance of the latter? The answer to this question is the dependency injection technique.

The technique of providing objects to another object that depends on them is called dependency injection:

When the functional architecture of an application requests an instance of a parent object, some code, such as an injector that is part of the non-functional architecture, creates and provides it, and at the same time creates an instance of a child object (or dependency) and assigns (or injects) it to the parent object. All the above is made possible by the fact that both objects, parent and child, agree to function according to the interface.

Unit Testing Compliance

Any public method of a class that is part of a business domain can be unit tested, except in the following three cases:

1. The method we are testing belongs to a class that is an integration component by nature, such as a data access component.

2. The method we are testing belongs to a class that uses a communication component.

3. The method we are testing creates an object of a different type within itself.

Programming to Interfaces

Should we write a unit test that asserts that the method signature has not changed? No, we should not. Once a class is exposed to external use, the signature of its public members cannot be changed under any circumstances, because they represent the informal interface of the component. It would be nice to have a formal interface that defines the desired functionality implemented by a class, but the software design principle of "programming to interfaces" is not always used, despite the obvious benefits it provides. Regardless of whether an interface is formal or informal, its existing members cannot be changed once the interface is published. The only action that can be performed on existing interface members is to mark them as obsolete. However, new members can be added to the interface because they do not break the backward compatibility of the interface with previous versions of the software product.

Once changes to interface members are prohibited, there is no need to write unit tests that check for such changes.

Table of Content Software Development Pitfalls Previous: Business Logic Development Pitfalls