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
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
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
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