The document outlines various testing strategies in software development, emphasizing the importance of choosing appropriate techniques based on context. It discusses different types of tests such as acceptance, unit, and integration tests, while highlighting best practices for test-driven development (TDD) and common pitfalls to avoid. The author stresses the importance of focusing on external behaviors, managing complexity, and ensuring robust domain-driven tests to improve software quality.

1. Write Antifragile & Domain-Driven
Tests with
• THOMAS PIERRAIN
(@TPIERRAIN)
ACCEPTANCE TESTS
(COARSE-GRAINED “UNIT” TESTS)
UNIT TESTS
(FINE-GRAINED)
CONTRACT TESTS
INTEGRATION TESTS
QA
SMOKE TESTS
EXPLORATORY TESTS
END-TO-END TESTS
OUTSIDE-IN
DIAMOND
TDD

2. Disclaimers
There is no silver bullet Your testing strategy & techniques must always be
chosen accordingly to your context (both human & technical)
As long as you understand your trade-offs there is no reason not to
explore new paths…
Thanks to Kent Beck, Martin Fowler, Michael Feathers, Nat Pryce & Steve Freeman for their great source of
inspiration over the years #shouldersOfGiants

3. Preamble

4. BFF API
Booking
API
E-commerce
CRS API
Central
Reservation
U
d
PSP
API
Payment
U
d
• THOMAS PIERRAIN
(@TPIERRAIN)
Metasearch
API
Distribution
U
d
Resorts
Referential
CMS
API
Property
Management
System (PMS)
Stay
U
d
U
d
Rates &
Cancellation rules
API
Revenue Mgmt
U
d
U
d
Hospitality
U
d
Accounts
API
Loyalty
API
Marketing
DDD
LOVES…
(Contextualized)
Services

5. E-commerce
Central
Reservation
U
d
Payment
U
d
• THOMAS PIERRAIN
(@TPIERRAIN)
Distribution
U
d
Resorts
Referential
Stay
U
d
U
d
Revenue Mgmt
U
d
U
d
U
d
Marketing
Accounts
API
Loyalty
API
DDD
LOVES…
(Contextualized)
Services
BFF API
Booking
API
CMS
API
PSP
API
CRS API
Rates &
Cancellation rules
API
Metasearch
API
Property
Management
System (PMS)
Hospitality

6. • THOMAS PIERRAIN
(@TPIERRAIN)
DDD (& TDD)
ALSO
LOVES… DOMAIN
HTTP
HTTP
API
INFRASTRUCTURE
OUR WEB API
Ports &
Adapters

7. • THOMAS PIERRAIN
(@TPIERRAIN)
DDD (& TDD)
ALSO
LOVE… DOMAIN
HTTP INFRASTRUCTURE
OUR WEB API
Ports &
Adapters
Easy to test
Protect Domain code from
Infra fads
Quick feedback
(carpaccio-style slicing)
Allow late
architectural decisions
Composable:
modular-monolith ready HTTP
API

8. • THOMAS PIERRAIN
(@TPIERRAIN)
DDD (& TDD)
ALSO
LOVE… DOMAIN
INFRASTRUCTURE
Ports &
Adapters

9. • THOMAS PIERRAIN
(@TPIERRAIN)
DDD (& TDD)
ALSO
LOVE… DOMAIN
HTTP INFRASTRUCTURE
OUR WEB API
Ports &
Adapters
HTTP
API

10. Let’s talk about tests!

11. • THOMAS PIERRAIN
(@TPIERRAIN)
Different
Types
A WORLD
OF TESTS
ET Exploratory Tests (E2E)
IT Integration Tests (Contract)
AT
(coarse-grained unit)
Acceptance Tests
UT (fine-grained) Unit Tests

12. Why do I do TDD?

13. Made me…
• THOMAS PIERRAIN
(@TPIERRAIN)
TEST
DRIVEN
DEVELOP
MENT
More relaxed
More efficient
More relevant

14. TDD Workflows

15. Outside-in
• THOMAS PIERRAIN
(@TPIERRAIN)
TEST
DRIVEN
DEVELOP
MENT

16. Outside-in
• THOMAS PIERRAIN
(@TPIERRAIN)
TEST
DRIVEN
DEVELOP
MENT
AT

17. Outside-in
• THOMAS PIERRAIN
(@TPIERRAIN)
TEST
DRIVEN
DEVELOP
MENT
AT

18. Outside-in
• THOMAS PIERRAIN
(@TPIERRAIN)
TEST
DRIVEN
DEVELOP
MENT AT
AT

19. Outside-in
• THOMAS PIERRAIN
(@TPIERRAIN)
TEST
DRIVEN
DEVELOP
MENT AT
AT
AT

20. Outside-in
• THOMAS PIERRAIN
(@TPIERRAIN)
TEST
DRIVEN
DEVELOP
MENT AT
AT
AT
AT

21. Outside-in
• THOMAS PIERRAIN
(@TPIERRAIN)
TEST
DRIVEN
DEVELOP
MENT AT
AT
AT
AT
AT

22. Outside-in
• THOMAS PIERRAIN
(@TPIERRAIN)
TEST
DRIVEN
DEVELOP
MENT AT
AT
AT
AT
AT
AT

23. Outside-in
• THOMAS PIERRAIN
(@TPIERRAIN)
TEST
DRIVEN
DEVELOP
MENT
AT
AT
AT
AT
AT
AT
AT

24. Inside-out
• THOMAS PIERRAIN
(@TPIERRAIN)
TEST
DRIVEN
DEVELOP
MENT

25. Inside-out
• THOMAS PIERRAIN
(@TPIERRAIN)
TEST
DRIVEN
DEVELOP
MENT
UT

26. Inside-out
• THOMAS PIERRAIN
(@TPIERRAIN)
TEST
DRIVEN
DEVELOP
MENT
UT
UT
API

27. Inside-out
• THOMAS PIERRAIN
(@TPIERRAIN)
TEST
DRIVEN
DEVELOP
MENT
UT
UT
API UT

28. Inside-out
• THOMAS PIERRAIN
(@TPIERRAIN)
TEST
DRIVEN
DEVELOP
MENT
UT
UT
API UT
UT

29. Inside-out
• THOMAS PIERRAIN
(@TPIERRAIN)
TEST
DRIVEN
DEVELOP
MENT
API
UT
UT
UT
UT
UT

30. Inside-out
• THOMAS PIERRAIN
(@TPIERRAIN)
TEST
DRIVEN
DEVELOP
MENT
API
UT
UT
UT
UT
UT
UT

31. Inside-out
• THOMAS PIERRAIN
(@TPIERRAIN)
TEST
DRIVEN
DEVELOP
MENT
API
UT
UT
UT
UT
UT
UT
UT

32. Inside-out
• THOMAS PIERRAIN
(@TPIERRAIN)
TEST
DRIVEN
DEVELOP
MENT
API
UT
UT
UT
UT
UT
UT
UT
AT

33. Inside-out
• THOMAS PIERRAIN
(@TPIERRAIN)
TEST
DRIVEN
DEVELOP
MENT
API
UT
UT
UT
UT
UT
UT
UT
AT
AT

34. Workflows
• THOMAS PIERRAIN
(@TPIERRAIN)
TEST
DRIVEN
DEVELOP
MENT
Outside-in Inside-out
A
P
I
…
…
A
P
I

35. Common pitfalls & mitigations

36. • THOMAS PIERRAIN
(@TPIERRAIN)
Beware of…
TEST
DRIVEN
DEVELOP
MENT
1. Fragile tests
2. Blind spots
3. Complex setups

37. TEST
DRIVEN
DEVELOP
MENT
1.
Beware of…
Fragile tests
uses
API
uses

38. • THOMAS PIERRAIN
(@TPIERRAIN)
TEST
DRIVEN
DEVELOP
MENT
AT
UT
UT
UT
UT
UT
UT
AT
uses
API
1.
Beware of…
Fragile tests

39. • THOMAS PIERRAIN
(@TPIERRAIN)
TEST
DRIVEN
DEVELOP
MENT UT
UT
AT
UT
UT
UT
UT
AT
uses
API
Now we want to change
our implementation here
1.
Beware of…
Fragile tests

40. • THOMAS PIERRAIN
(@TPIERRAIN)
TEST
DRIVEN
DEVELOP
MENT UT
UT
AT
UT
UT
UT
UT
AT
uses
API
1.
Beware of…
Fragile tests

41. • THOMAS PIERRAIN
(@TPIERRAIN)
TEST
DRIVEN
DEVELOP
MENT UT
UT
AT
UT
UT
UT
UT
AT
😕
😕 😕
😕
😕
uses
API
1.
Beware of…
Fragile tests
😕

42. • THOMAS PIERRAIN
(@TPIERRAIN)
TEST
DRIVEN
DEVELOP
MENT UT
UT
AT
UT
UT
UT
UT
AT
😕
😕 😕
😕
😕
uses
API
Fragile tests
➔ Less refactoring
😕

43. • THOMAS PIERRAIN
(@TPIERRAIN)
UT
UT
AT
UT
UT
UT
UT
AT
😕
😕 😕
😕
😕
uses
API
TEST
DRIVEN
DEVELOP
MENT
Fragile tests
MITIGATIONS
• Do not test “implementations”
• Focus on external behaviours
instead (with Outside-in TDD)
• Favor (coarse-grained unit)
Acceptance tests over fine-
grained unit tests
A
P
…
…

44. • THOMAS PIERRAIN
(@TPIERRAIN)
TEST
DRIVEN
DEVELOP
MENT Disclaimer
Test Coverage will be a visual help to
identify blind spots in our code here
It doesn’t mean that test coverage is a
must
2.
Beware of…
Blind Spots

45. • THOMAS PIERRAIN
(@TPIERRAIN)
TEST
DRIVEN
DEVELOP
MENT
DOMAIN
HTTP
HTTP
API
INFRASTRUCTURE
OUR WEB API
2.
Beware of…
Blind Spots

46. • THOMAS PIERRAIN
(@TPIERRAIN)
TEST
DRIVEN
DEVELOP
MENT
DOMAIN
Test the domain code with
{ acceptance | unit tests }
2.
Beware of…
Blind Spots

47. • THOMAS PIERRAIN
(@TPIERRAIN)
TEST
DRIVEN
DEVELOP
MENT
DOMAIN
HTTP
API
Test the domain code with
{ acceptance | unit tests }
Test the infra code (i.e. Adapters) with
contract (integration) tests
2.
Beware of…
Blind Spots

48. • THOMAS PIERRAIN
(@TPIERRAIN)
TEST
DRIVEN
DEVELOP
MENT
2.
Beware of…
Blind Spots
IT
IT
IT
IT
HTTP
API

CONTRACT TESTS
DOMAIN
AT
AT
AT
AT
AT
AT
AT
AT
AT
AT
AT
AT
AT
AT
AT
100% covered
by Acceptance
Tests

49. • THOMAS PIERRAIN
(@TPIERRAIN)
TEST
DRIVEN
DEVELOP
MENT
2.
Beware of…
Blind Spots
IT
IT
IT
IT
HTTP
API

CONTRACT TESTS
DOMAIN
AT
AT
AT
AT
AT
AT
AT
AT
AT
AT
AT
AT
AT
AT
AT
100% covered
by Acceptance
Tests
As DEV we
to write Domain-
Driven tests

50. • THOMAS PIERRAIN
(@TPIERRAIN)
TEST
DRIVEN
DEVELOP
MENT
2.
Beware of…
Blind Spots
IT
IT
IT
IT
HTTP
API

CONTRACT TESTS
DOMAIN
AT
AT
AT
AT
AT
AT
AT
AT
AT
AT
AT
AT
AT
AT
AT
100% covered
by Acceptance
Tests
As DEV we
to write Domain-
Driven tests

51. • THOMAS PIERRAIN
(@TPIERRAIN)
TEST
DRIVEN
DEVELOP
MENT
2.
Beware of…
Blind Spots
As DEV we don’t write
enough integration tests
Because they are slow to
run & boring
➔ BUGS
IT
IT
IT
IT
HTTP
API

CONTRACT TESTS
DOMAIN
AT
AT
AT
AT
AT
AT
AT
AT
AT
AT
AT
AT
AT
AT
AT
100% covered
by Acceptance
Tests
As DEV we
to write Domain-
Driven tests

52. As DEV we don’t write
enough integration tests
Because they are slow to
run & boring
➔ BUGS
IT
IT
IT
IT
HTTP
API

CONTRACT TESTS
DOMAIN
AT
AT
AT
AT
AT
AT
AT
AT
AT
AT
AT
AT
AT
AT
AT
100% covered
by Acceptance
Tests
As DEV we
to write Domain-
Driven tests
• THOMAS PIERRAIN
(@TPIERRAIN)
TEST
DRIVEN
DEVELOP
MENT
Blind Spots
MITIGATIONS
• Detect bugs in Adapters
via our beloved Acceptance
tests
• Include the Adapters code
and stub only the I/Os
BUGS

53. • THOMAS PIERRAIN
(@TPIERRAIN)
TEST
DRIVEN
DEVELOP
MENT
3.
Beware of…
Complex
setups

54. • THOMAS PIERRAIN
(@TPIERRAIN)
Test Suite for Rooms Availability
TEST
DRIVEN
DEVELOP
MENT
3.
Beware of…
Complex
setups
740 lines of Init()

55. • THOMAS PIERRAIN
(@TPIERRAIN)
Test Suite for Rooms Availability
TEST
DRIVEN
DEVELOP
MENT
3.
Beware of…
Complex
setups
740 lines of Init()

56. • THOMAS PIERRAIN
(@TPIERRAIN)
Test Suite for Rooms Availability
TEST
DRIVEN
DEVELOP
MENT
3.
Beware of…
Complex
setups
740 lines of Init()

57. • THOMAS PIERRAIN
(@TPIERRAIN)
Test Suite for Rooms Availability
TEST
DRIVEN
DEVELOP
MENT
3.
Beware of…
Complex
setups
Tests using initialized fields
➔ side effects nightmare

58. • THOMAS PIERRAIN
(@TPIERRAIN)
MITIGATIONS
• Avoid cognitive overload as much as
possible
The power of sameness
• Favor local variables over test suite
members
Everything should be created from the test
• Use Domain-Driven Builders to shorten
and explicit the Arrange section of your
tests
• Treat your test code as production code!
➔ merciless refactoring
TEST
DRIVEN
DEVELOP
MENT
3.
Beware of…
Complex
setups

59. • THOMAS PIERRAIN
(@TPIERRAIN)
Beware of…
TEST
DRIVEN
DEVELOP
MENT
1. Fragile tests
2. Blind spots
3. Complex setups

60. • THOMAS PIERRAIN
(@TPIERRAIN)
1. Fragile tests
2. Blind spots
3. Complex setups
Mitigations
TEST
DRIVEN
DEVELOP
MENT

61. • THOMAS PIERRAIN
(@TPIERRAIN)
1. Fragile tests
2. Blind spots
3. Complex setups
Mitigations
TEST
DRIVEN
DEVELOP
MENT

62. • THOMAS PIERRAIN
(@TPIERRAIN)
1. Fragile tests
2. Blind spots
3. Complex setups
Mitigations
TEST
DRIVEN
DEVELOP
MENT

63. Outside-in Diamond TDD

64. Outside-in Diamond TDD

65. Outside-in Diamond TDD

66. • THOMAS PIERRAIN
(@TPIERRAIN)
Outside-in
but…
TEST
DRIVEN
DEVELOP
MENT
Double loop?

67. • THOMAS PIERRAIN
(@TPIERRAIN)
Outside-in
but…
TEST
DRIVEN
DEVELOP
MENT
Double loop

68. • THOMAS PIERRAIN
(@TPIERRAIN)
Outside-in
but…
TEST
DRIVEN
DEVELOP
MENT
Double loop
One and a half loop
( )

69. OUTSIDE-IN
DIAMOND

70. OUTSIDE-IN
DIAMOND

71. OUTSIDE-IN
DIAMOND
Read it as a sentence divided into 2 parts
+

72. OUTSIDE-IN
DIAMOND
Fuzzers help us
- to randomly detect hard-coded values
or unsupported cases

73. OUTSIDE-IN
DIAMOND
Fuzzers help us
- to randomly detect hard-coded values
or unsupported case
- to shorten our test setup

74. OUTSIDE-IN
DIAMOND
Builders allow Behavioral
& Domain-Driven intentions
(no tech details here)

75. OUTSIDE-IN
DIAMOND
Builders allow Behavioral
& Domain-Driven intentions
(no tech details here)

76. OUTSIDE-IN
DIAMOND
Builders allow Behavioral
& Domain-Driven intentions
(no tech details here)

77. OUTSIDE-IN
DIAMOND
Builders allow Behavioral
& Domain-Driven intentions
(no tech details here)

78. OUTSIDE-IN
DIAMOND
Builders allow Behavioral
& Domain-Driven intentions
(no tech details here)

79. OUTSIDE-IN
DIAMOND
Builders allow Behavioral
& Domain-Driven intentions
(no tech details here)
Very important!

80. OUTSIDE-IN
DIAMOND
We test from the left-side Adapter
(here a web controller)
Injecting the result of our builder

81. OUTSIDE-IN
DIAMOND
We define the end-user request
No I/O here, but we test
the whole { black-box / component / API }

82. OUTSIDE-IN
DIAMOND
Helper method to sum-up in “one line”
our assert intention

83. OUTSIDE-IN
DIAMOND
“One line” to hide our
technical assertions
towards DTOs etc.

84. OUTSIDE-IN
DIAMOND
“One line” to hide our
technical assertions
towards DTOs etc.
“One line” to reuse the same
check intention, but with
various adapters

85. OUTSIDE-IN
DIAMOND

86. OUTSIDE-IN
DIAMOND

87. OUTSIDE-IN
DIAMOND

88. OUTSIDE-IN
DIAMOND

89. OUTSIDE-IN
DIAMOND

90. OUTSIDE-IN
DIAMOND
ARRANGE
ACT
ASSERT

91. OUTSIDE-IN
DIAMOND
ARRANGE
ACT
ASSERT
Fuzzers to shorten & speed setup
Builders to shorten and
“domain-driven” our test setup

92. OUTSIDE-IN
DIAMOND
Domain-Driven!

93. Live code

94. Wrap up

95. Outside-in Diamond TDD
• Elaborated from & for the people
• Write fast & Antifragile tests
( refactoring )
• DDD but covers more blind spots
on the tech side

96. Outside-in Diamond TDD
• Elaborated from & for the people
• Write fast & Antifragile tests
( refactoring )
• DDD but covers more blind spots
on the tech side

97. Any Questions?

98. BINARY IS FOR MACHINE
CODE IS FOR PEOPLE
WE CARE PEOPLE
Special thanks to: Bruno BOUCARD, Cyrille DUPUYDAUBY & Rui CARVALHO for their kind reviews & feedbacks