Let’s see how a testable software architecture is also modular, and vice versa!

Practical Definition of Testability

Testability is the quality which enables the developer to easily test a software component separately from the rest of the architecture.

Thus, a testable architecture is one which is made of components that are easily testable in isolation.

How do the latter sentences relate to modularity?

Testability Issues Imply Modularity Issues

Simply put, any difficulty in testing a component separately from its architecture context, indicates lack of modularity.

Consequently, if it’s difficult to test a component in isolation, then the architecture is neither testable nor modular.

Reasons Behind Lack of Testability

Lack of testability (i.e., lack of modularity) in an architecture sets in in the presence of highly coupled and low cohesive components, contrary to the definition of modularity.

Brief recap from “Software Architecture Design Fundamentals for Busy Developers”: a modular architecture is made of loosely coupled and highly cohesive components.

As a matter of fact, highly coupled and low cohesive components are very difficult to test independently from each other, let’s see how.

Highly Co-Dependent Components with Low Cohesive Functionalities

Any highly coupled component being put in isolation will instantly exhibit unmet external dependencies, which require difficult mocking.

Namely, the implementation of complex software artifacts must be carried out in order to replicate the missing functionalities which the component depends on.

The lower the cohesiveness of functionalities within a component under test, the higher the number of unmet co-dependencies to be replicated.

In conclusion, a non-modular architecture makes testing activities tedious, error-prone, and time-consuming because of difficult mocking to be undergone.

Practical Testability-Based Architecture Design

Taking into account testability makes architecture design more practical and effective.

Namely, designers together with developers can help each other make better design decisions due to the following facts.

First, any testability issue in the initial design indicates lack of modularity, which is a clear and useful warning sign for designers.

Second, developers can concretely point out potential testability issues in the initial design, which makes the decision-making process more practical.

Last but not least, designing an architecture in the above-mentioned way helps to effectively tackle software erosion phenomenon by:

  • keeping the architecture modular (i.e., testable), as well as
  • keeping the implementation aligned with the corresponding architecture.