Presentation that was used as a background for a talk during SoftwareCraftsmanship Silesia meetup (http://www.meetup.com/sc-silesia/events/217544292/). Code examples described during the meetup are accessible on bitbucket: https://bitbucket.org/szymon_homa/tdd-ddd_airport

1. Szymon Homa
Approach to automated
tests with DDD and
Hexagonal Architecture as a
background.
@s2lomon

2. Hexagonal Architecture
Alistair Cockburn, Hexagonal Architecture

3. Hexagonal Architecture with a little bit of DDD
Alistair Cockburn, Hexagonal Architecture
Domain Model

4. Hexagonal Architecture along with
Bounded Context
Alistair Cockburn, Hexagonal Architecture

5. Hexagonal Architecture
Alistair Cockburn, Hexagonal Architecture
Domain Model
Direction of
Interactions

6. Tests of a Model
Domain Model
Alistair Cockburn, Hexagonal Architecture
100% Unit Test (TDD)
Classic TDD is the best option
in a vast majority cases
Test Double can be used only in a case
of having a pure abstraction
(like Strategy/Specyfication pattern)
It’s good to have a Test Fixture

7. Tests of an Application Layer.
Domain Model
Alistair Cockburn, Hexagonal Architecture
Test Double almost allways when we
interact with another service, or separated
functionality
We should be using Model as it is
(without Test Double)
Model can (should) be produced by a same
Test Fixture
From time to time we can use Dummy
instead of an actual implementation.

8. Tests in an Infrastructure Layer
Domain Model
Alistair Cockburn, Hexagonal Architecture
Integration tests should prevail
Unit tests should be used only for classes
that contains logic required to implement
the actual adapter, like Assembler,
Query Builder etc.
Good place for acceptance tests
"Test Double" can be occasionally used for
external interfaces

9. Thanks