T stands for testing. Understand it first. Chapter 2 — The Missing puzzle.

Solution for the problems on unit testing and TDD.

Jakub Pruszyński
3 min readOct 17, 2021
Photo by Sigmund on Unsplash

In Chapter 1 of this series we have mentioned, that tests are nothing more than just a code. According to this, they should be treated as carefully as production. Therefore, to accomplish that, we need to sort out one more thing — their place in the architecture, eventually each application has some. Hexagonal architecture known as Ports-Adapters architecture or Clean architecture, thanks to it popularity, will be our base to dicuss the issue.

Whilst software development, we are forced to make hundreds small decisions on the daily basics, many of these choices is based on two broadly-known rates — coupling and cohesion. These index is telling us, about relationship between different parts of software.

https://www.coursera.org/lecture/object-oriented-design/1-3-1-coupling-and-cohesion-q8wGt

Coupling is the degree of independence between modules

Cohesion is the degree of dependence between elements of the same module

Agile software is a software with low coupling and high cohesion.

The rule above concerns to every layer of abstraction, from single method or class to high-level modules. As such, it usage allows us to refactor in simple and plausible manner over time. That is why, we should apply it in the context of dependency between testing code and tested one.

It is worth to mention about one more relevant tests aspect, because of their purpose, they are characterize by high detaildeness, concretness and dependence always directed towards tested code. It implies that they are depending on everything and nothing depends on them. Therefore tests should be treated as the most outer layer of clean architecture.

https://dzone.com/articles/onion-architecture-is-interestingtestów

By extension, we have placed tests in the right place in the architecture of our application. Thanks to that another revelation appeared to us — the proper way of testing — testing by API.

It is arisen by clean architecture’s nature :

  • each layer can communicate only with the layer below
  • the communication between layers is based on API

That observation in terms of tests is perfectly summarized by Uncle Bob.

But if you want to properly decouple your tests from your production code, you design an API for those tests. By the way, that API will also be the API that other layers of the system use to communicate.

— Giving Up on TDD Robert C. Martin

It is important to emphasize — testing by the API is not the same as testing through public methods because API is far more vast notion and we will unfold that in the Chapter 3. Moreover in the next article we are going to introduce ABC model, which allow for effective testing of modules as units in vertical architecture. The model that successfully have been introduced in my team.

Please, don’t forget to clap and follow, but only if I earned ;)

Cheers!!

--

--

Jakub Pruszyński

senior android developer, reading & learning enthusiast