This document discusses a testing strategy for hexagonal applications that focuses on testing units in isolation like domain logic and use cases without infrastructure dependencies. It advocates for unit tests of application services, integration tests of port adapters against real databases/services, and system tests of the full deployable application to build testing confidence from the unit to system level. The key aspects of hexagonal architecture that enable this are isolation of domain from infrastructure through ports/adapters and explicit definition of use cases as primary interaction points.

1. A Testing Strategy for Hexagonal
Applications
Matthias Noback
@matthiasnoback

2. A test is not a unit test if:
● It talks to the database
● It communicates across the network
● It touches the file system
● It can't run at the same time as any of your other unit
tests
● You have to do special things to your environment
(such as editing config files) to run it.
Michael Feathers: https://www.artima.com/weblogs/viewpost.jsp?thread=126923

3. A unit test:
● It's deterministic
● It's fast
● It makes it easy to uncover the
reason of failure

4. The relation with hexagonal
architecture?
Hexagonal architecture automatically allows you
to test bigger parts of your application in "the unit
test way".

5. Isolation is key
Separating domain from infrastructure code
==
Automatic and guaranteed increase of testability

6. Hexagonal architecture
benefit no
2
Explicitly designed use cases, which are
recognizable as such

7. A port:
An intention of communication

8. An adapter:
The supporting technology for that communication

9. Ports
● Incoming: primary actors (users,
other systems calling us)
● Outgoing: secondary actors
(databases, other systems we call,
etc.)

10. Combining these two
qualities of hex. arch.
● We can test more of our code "the
unit test way"
● We distinguish ports as our
application's use cases
● Means...

11. We can test our use cases using fast tests that are
close to the domain and follow the definition of a
unit test

12. Examples of use cases and
their interactions
● Create a new meetup group
● Schedule a meetup
● Accept registrations
● List upcoming and past meetups
● Show details about talks, organizers,
etc.

13. Without infrastructure
● No framework
● No controller action
● No database
● No external services
● No filesystem
● No system clock
● No randomness

14. Application service
Repository interface
calls
uses
implements
W
ebcontroller
Testdriver
MySQL
Stub
calls
implements

15. How do we know if it
works in production?
We have interfaces for every port...

16. How do we know if it
works in production?
Now we should prove that the port adapters
implement these contracts correctly

17. Adapter tests are called "Integration tests"

18. Integration tests
● Test a repository against the actual
database
● Test an HTTP integration against the
real webservice
● Test an application service using a real
web controller

19. Application service
W
ebcontroller
MySQL
calls
Repository interface
implements

20. What's missing?
A way to be sure that the deployable unit works

22. System tests
● Everything configured as much as
possible like the real thing
● Only a few tests ("smoke tests")

23. Building confidence
● Unit
● Acceptance
● Integration
● System

24. Advantages
● Ability to catch bugs where they are
● Ability to postpone infrastructure
decisions
● Ability to show to domain experts
what you have done and talk about
missing scenarios/examples

25. Matthias Noback
@matthiasnoback