In the book
Growing Object-Oriented Software, Guided by Tests
, we described various types of tests that we use to design software and showed how well they are combined with the architectural style of Ports and Adapters ( ) Ports and Adapters by Alistair Cockburn
 
In Ports and Adapters, the domain of the application is the domain model, which has no points of contact with any parts of the infrastructure, be it databases, queues, UI, etc. But the model contains interfaces that define its relationship with the outside world in terms of a domain. Cockburn calls these interfaces ports. These interfaces are implemented in the relevant objects that interact with the outside world - Cockburn called them adapters. In distributed systems, different processes, each with their own domain model, interact with each other through ports and adapters.
 
In the diagram above, a large circle is a process, small (inside it) - objects. The domain is located in the center of the process. Infrastructure modules (in the figure are signed sectors), through which the process interacts with the outside world, stuck in the domain "circle." Modules-adapters that map domain concepts to technical implementations are located between them.
 
Below I will try to explain how different levels of testing fit into Ports and Adapters.
 
Modular tests
 

 
Unit tests test individual objects, or their small groups within a single process. For example, with Test-Driven Development, we write unit tests, the results of which affect the tested code-we edit it when it does not pass any test case.
 
Integration tests
 

 
The term "integration tests" can be applied to many types of testing. In our book, we used it to denote tests for some abstraction from our code, which is implemented using third-party packages. Here we want to suggest that our implementation of the abstraction correctly integrates with the third-party code: to make sure that we have not made wrong assumptions about how it works and just does not stumble over any mistakes we have not taken into account. However, we can not directly correct the errors found by these tests, because we do not have access to the tested (third-party) code.
 
Acceptance tests
 

 
Acceptance tests are tests that are user-oriented, they test the domain logic of the entire sibling, and demonstrate that it actually works as expected.
 
Ports and adapters allow you to run acceptance tests right for the domain layer, because it is completely isolated from the technical infrastructure and the real world. Acceptance tests can interact with the model via port interfaces. Such tests will be fucking fast. They can also be easily isolated from each other, because they do not preserve the state of the model (in the database or in the queue, for example).
 
Acceptance tests for a distributed system can initialize the domains of different processes in the shared memory and refer to each other using the implementations of their port interfaces, which will allow each particular test not to go beyond the boundaries of its process.
 
System tests
 

 
System tests, test the whole system, managing it, through open ports. They also test the assembly, deployment and loading of the system. Writing system tests at the early stages of development, ensures that the system will always be ready for the de- lay as it develops.
 
However, such tests are wildly inhibitory + the real conditions in which they are run (parallelism, asynchrony, the need to save data) make it difficult to write readable tests isolated from each other.