How big should a "Unit" be?

This article is an extended version of my thoughts on the topic of Unit Testing, originating from a discussion with Adrian Stanek , and James Galyen .

What is a "Unit" in Unit Testing?

The common definition of unit testing, reads:

unit testing is a software testing method by which individual units of source code —sets of one or more computer program modules together with associated control data, usage procedures , and operating procedures—are tested to determine whether they are fit for use

While this definition makes sense, it does not offer any practical guidance on what the size of a unit should be. When asked, most software developers fall into one of two schools of thought:

• A "unit" is a class, or any public method in a class.
• A "unit" is a collection of classes, within the same module, that contribute to a single functionality.

Personally, I lean towards to the second school of thought. In this article, I will dive into how we can define the boundaries of a "unit" for testing purposes.

Q: So, how big should a "unit" be?

A: It depends. ??

Understanding System Boundaries

To give you a coherent, and practically oriented, breakdown of my thoughts on the matter, let's take a look at an example system design. The system depicted in the sketch below is an n-tier reference architecture with two user-facing components: a web-based user interface application and a command-line interface application. Both of these connect to the backend system through API calls. At the far end of the system are two distinct data storage systems (databases) used to persist the system's data.

We can define the following layers:

• User Control: Components that allow for user interaction to the system. Contains the CLI and UI components.
• Public interfaces: Technical interfaces to the functionality offered by the system. Contains API controllers that expose system logic.
• Logic: business rules and logical services, built from models and functions that describe the solution domain.
• Data Access: provides transparent access to the persistent storage solution (usually a database or external system connection).
• Storage & external system calls: the storage solutions and external systems exposed by the Data Access layer. Contains elements that offer persistence functionality to the system.

Now that we have an overview of our system from a structural point of view, let's add some more specifics to make it more realistic and tangible. We will assume the UI is a a web application written in a popular JavaScript framework, and that the interface elements are JSON/HTTP controllers that do some minimal mapping. The data access services house ORM framework models.

Our system offers three main functionalities, two of which are exposed through the web interface, the third is only accessible through the CLI interface. Let's say this third functionality pertains to administrative tasks that are not relevant for the end-users, but are required for application management.

Technical versus functional boundaries

The challenge in defining the boundary of a testing unit arises from the desire to find a one-size-fits-all scope. In practice, your goal is not to find an academic solution but to write tests for specific purposes, usually to validate the functionality or quality attributes of a system. Let's explore the downsides of using common test unit scopes, such as layers and functional slices.

Using layers to define units

Our example architecture is structured in layers, commonly referred to as an "n-tier" architecture. In this concept, each layer has a specific purpose. The overall system is composed of multiple layers, each depending only on the functionality offered by the layer directly below it. We could scope our units to be "one element in one single layer".

This makes sense when testing your data access layer, as you want to answer the question: "Are my objects serialized, stored, and de-serialized correctly?".

The layer-based approach becomes trickier when moving up to the top-level layers. Consider how you would test the API controllers in isolation. Their responsibility is generally minimal: accept and incoming http message, possibly transform this to an internal representation, and delegate that to the relevant business logic service. If we assert that the "correct service" is called, we are no longer testing functionality, but adding a structural requirement to our system: "this API will always call this service". Do this a few times, and your system becomes difficult and costly to change. Let's say a few months from now, we decide to extract some methods from the existing services and bundle them together into a new business service.

So, what happens to our existing API tests after our restructuring?

They will all start failing, as we wrote them to assert they are calling a specific method in a specific service. The code snippet below illustrates such a test.

Using slices to define units

Rather than using the layers, we could also use functional slices as boundaries for our Units. The disadvantage of this approach is quite obvious: it is easy to test too much of your system. At this point, your test is no longer "lean and mean" and is crossing over into integration-test territory as you will need to instantiate a significant part of your system in order to run your test.

Recalling our system example, we could stub out the databases or use an in-memory test database. While these are sensible approaches to minimize how much of your system you need to spin up to run your test -- and can arguably be considered to be "unit tests" -- they still come at a cost of significantly increasing your test suite's execution time.

Advised approach: matching boundaries to test

What is internal vs what is external, and by consequence: what scope a "unit" is, depends on what you are testing.

As such, you are usually better off focusing on defining "responsibility units", and testing those using whatever elements are most relevant to the functionality you wish to assert. While doing this, try and minimize the amount of elements you need to instantiate.

In other words: Depending on what functionality you are looking to validate, your unit size should vary to contain strictly the components that are responsible for supplying this functionality.

Note that this means you will probably not explicitly test all possible code paths at build time. And that is fine. You can usually assume that a function call will happen correctly. If you want to have the additional assurance: add smoke tests or integration tests to make sure your system behaves normally.

Let's apply this approach to our example system.

• Say I want to test the mapping of my API layer. I would define my unit as being only the API, and related mappers. Everything else is external to this responsibility scope, and should be stubbed/mocked. We can now test the mapping in isolation.
• Say I want to test the "A user can create an account"-functionality. The responsibility boundary would now contain: the relevant API, and the business service. Assuming we have tested the "data can be stored and retrieved"-functionality on the DAO layer, we can stub this layer out.
• Say I want to test the Data Access service responsible for storing user information. I would set up an in-memory database (or test container) to minimize relying on the presence of a real database cluster. I can now write a test that takes an object to be stored, stores it, retrieves it, and asserts that the retrieved object is the same as what I put in. Attentive readers might notice this approach avoids the test breaking if the data object changes, as I am testing that storing+retrieving data from the storage is symmetrical.

TLDR / Key takeaways

• What is internal vs what is external, and by consequence: what a unit is, depends on what you are testing, and can vary from one test to the next.
• It is easier to define boundaries for your test scopes if you are able to assign specific responsibilities to your system elements.
• Avoid describing an element's purpose as "A calls B". If your elements are really that dumb, do not bother testing them.
• The split between "unit tests" and "integration tests" is somewhat artificial, but boils down to: if you need to spin up a large part of your system in order to run the test, you are probably writing an integration test.

References and further reading

• The post by Adrian Stanek that led to this article: https://www.dhirubhai.net/posts/adrianstanek_softwareengineering-communication-activity-7125755594849804290-s9II?utm_source=share&utm_medium=member_desktop
• My description of the "Testing Pyramid" concept, on my public knowledge sharing repository. https://patterns.sddevelopment.be/concepts/testing_pyramid/
• Beck, K. (2023) Test Desiderata. Self publish on GitHub Pages. https://kentbeck.github.io/TestDesiderata/
• Fowler, M.; Beck, K.; Brant J.; Opdyke W.; Roberts D. (2012) Refactoring: Improving the Design of Existing Code. Addison-Wesley Professional. isbn: 9780133065268. https://www.goodreads.com/book/show/18624706-refactoring
• Farley, D. (2021) Modern Software Engineering. . isbn: 9780137314911. https://www.amazon.com/Modern-Software-Engineering-Discipline-Development/dp/0137314914