Hexagonal Architecture
A question that is often raised is: how do I practice TDD when I have to deal with the dependencies of my system to the outside world? Examples of such dependencies are databases, file systems, networks, etc. So isn't it inevitable then that I eventually have to include tests involving these external systems in my tests and as a consequence my tests (gradually) become slow?
Many people are inclined to introduce mocks into their tests at this point, but apparently these people haven't heard of the don't mock what you don't own principle. A good but somewhat long read about this topic is also Martin Fowler's well-known mocks aren't stubs.
Since some of the coding katas in this repository specifically address this topic, this page discusses the required concepts that are common to all these katas. These concepts all fall under the umbrella of what's generally known as the Hexagonal Architecture (a.k.a. Ports and Adapters). Uncle Bob made this concept known as clean architecture.
For the coding katas, the most important concepts to apply are dependency inversion and (ports and) adapters.
-
Dependency Inversion is the last of the five well-known SOLID principles. In a nutshell, it boils down to dictating to the outside world what the data should look like, as opposed to letting the outside world determine your (object) model. The idea is to think in terms of the domain model first and to make the primary and secondary actors comply with the ubiquitous language established by our domain model. This implies e.g. that no field names or data models from external systems should be able to "leak" into our domain model!
-
Ports and adapters: as is explained in this article, "The main principle of the Ports & Adapters architecture is to have inputs and outputs on the edges of technology-agnostic code".
By simultaneously applying the adapter pattern (which is polymorphic by definition), we keep our system under development testable.
