Let me share a story about how John (a developer like any other) started to understand (and enjoy) writing Tests before the Production code. We've all felt an inevitable "tedium" when writing tests, haven't we? If it's boring, if it's complicated or unnecessary? Isn't it? John thought so too, and, as much as he had heard about writing tests before production code, he had never managed to put it into practice, and even when he had tried, John had become even more frustrated at not understanding how to put it into practice outside of a few examples katas 🤷‍♂️ Listen to this story in which I will explain how John went from not understanding Test Driven Development (TDD) to being passionate about it... so much that now he doesn't want to work any other way 😅 ! He must have found some benefits in practising it, right? He says he has more advantages than working in any other way (e.g., you'll find defects earlier, you'll have a faster feedback loop or your code will be easier to refactor), but I'd better explain it to you in the session, right? PS: Think of John as a random person, as if he was even the speaker of this talk 😉 ! --- Presentation shared at ViennaJUG, June'25 Feedback form: https://bit.ly/john-like-tdd-feedback

1. How John started to like TDD
(instead of hating it)
June, 2025

2. i
Who am I?
Nacho Cougil
Principal Software Engineer at Dynatrace
TDD & clean code fan
Started to write in Java before Y2K
Founder of the Barcelona Java Users Group (
BarcelonaJUG) & co-founder of the Barcelona
Developers Conference (DevBcn) former Java and
JVM Barcelona Conference
Java Champion
Father, former mountain marathon runner 😅
@icougil icougil.bsky.social
https://jvm.social/@icougil

3. 3

4. 4

5. 5

6. 6

7. 7
And at some point …
7

8. i
8
Lack of testing

9. i
9
Long-lived branches

10. Make others wait (until your work is done)
• The task XXX is not finished
• “Is because <write here your
excuse argument>”
• “We were waiting to do Y… based on
what you have to finish with Z”
• “Our feature was based on your
implementation around X”
10

11. New requests came in
11
• Sometimes were…
• Interesting
• Incompatible
• Incomprehensible
• Not mature enough
• …
• Too late

12. 12
Complexity

13. Many things to take into account
13
• Remember that…
• “When you have to do X … you must
have a record in the Database with Y”
• “Activate this flag in Z before running
A”
• “Remember to write into Kafka B after
doing C”
• “For testing D we need a license for E”
• “F is incompatible with the version G”
• …

14. 14
Adapt to changes

15. Invalid documentation
15
• Outdated
• Incorrect
• Missing…

16. 16
Limited time

17. 17
Building tests was boring

18. At the end… many reasons
18
• Lack of testing
• Long-lived branches
• Make others wait
• New requests came in
• Complexity
• Many things to take into account
• Adapt to changes
• Invalid documentation
• Limited time
• Building tests was boring

19. 19

20. 20

21. 21

22. 22
Same problems again !?

23. 23

24. 24
Questions came to his mind
• “There are surely practices to
improve”
• “There must be practices that
should help minimizing the risks”
• To share/deliver things faster and
with small chunks
• To not having to keep many
things in your mind
• To adapt to changes easily
• Have a better documentation
• Enjoy writing tests

25. 25
Learn from others
• Started attending meetups…
• Someone mentioned many
practices and concepts that he
didn’t know or he couldn’t practice
• Feedback-loop
• Simple design
• Small releases
• Pair-programming
• Refactoring
• Test Driven Development (TDD)

26. Started to grew
26
• Listening more
• Reading more books
• Practicing
• Personal projects
• Katas
• Writing less “smart” code
 more “easy to read” code,
easy to test code

27. 27
Tried to applied at work…
• Katas VS real projects
• Deadlines & commitments
• Initial time investment
• Learning curve
• Maintenance challenges
• Legacy projects
• Code does not do what you expect
• Lack of documentation
• Non-testable designed solution
• Different ways of developing
• Complexity

28. 28
Tried to applied at work…
• Couldn’t make it
• … ended up causing frustration

29. 29
Until one day…

30. 30

31. 31
1
2
3
Specify what you
would like to
implement
Develop what the
tests describes.
No more no less
TDD
Anything we can
leave better?
R
e
d
Green
R
e
f
a
c
t
o
r

32. 32
But, generalizing…
INPUT PROCESS OUTPUT

33. 33
But, generalizing…

34. 34
But, generalizing…
INPUT PROCESS OUTPUT

35. 35
But, how can we use TDD in a real-case scenario ?

36. i
36
Let’s see an example 🙂
• Build a solution that show on a website the
amount of resources (CPU usage, memory
consumption, etc) being used by different
services/endpoints
• A process must periodically check the
resources being used from different services
• We’ll act as we're Java/backend
developers (using Spring Boot)
😉
There are many ways to implement this,
depending on how we’d like to start:
1. The DB to the external endpoint ( from
the DB  business logic  endpoint )
2. The process that connects to the
services ( internal process  to the DB /
business logic  endpoint )
3. The external endpoint that triggers the
process to the DB ( endpoint  business
logic  DB )

37. 37
...
Service 1
https://service1...
DB
Sync Resource
Usages
Process
Usage
resources
Service 2
https://service2...
List Resource Usages
GET /resourceUsages
POST /resourceUsages/sync:execute
API

38. 1. From the DB to the external endpoint
( from the DB  business logic  endpoint )
2. From the process that connects to the services, to the DB and endpoint
( internal process  to the DB / business logic  endpoint )
3. From the external endpoint that triggers the process, to the DB
( endpoint  business logic  DB )
38
Approaches

39. 1. From the DB to the external endpoint
( from the DB  business logic  endpoint )
2. From the process that connects to the services, to the DB and endpoint
( internal process  to the DB / business logic  endpoint )
3. From the external endpoint that triggers the process, to the DB
( endpoint  business logic  DB )
39
Approaches

40. 40
1. From the DB to the external endpoint
Business layer Use cases (Services)
Presentation layer Controllers
Repositories
Data access
Storage
DB

41. 41
1. From the DB to the external endpoint
Time

42. 42
Change DB model
Change database
structure
1. From the DB to the external endpoint
Time

43. 43
Implement save usage
resources in a repository
Change DB model
Implement the
repository to save the
resource usage
(guessing how … 🤔 )
Change database
structure
1. From the DB to the external endpoint
Time
Questions araised 🤔
- Is it working as expected?
no tests at all
- Will we have to change something?
signatures will change?

44. 44
Implement save usage
resources in a repository
Change DB model Business logic: list of usage
resources to save
Implement the
repository to save the
resource usage
(guessing how … 🤔 )
Change database
structure
Implement part of the
business logic by
saving a list of usage
resources
(guessing how… 🤔)
1. From the DB to the external endpoint
Time
Questions 🤔
- Is it working as expected?
- Will we have to change something?
Questions 🤔

45. 45
Implement save usage
resources in a repository
Business logic: find all the
services and connect to all of
them, asking for their
resource usage
Change DB model Business logic: list of usage
resources to save
Implement the
repository to save the
resource usage
(guessing how … 🤔 )
Retrieve the list of
existing services and
for each one, connect
to it and ask for their
resource usage
Change database
structure
Implement part of the
business logic by
saving a list of usage
resources
(guessing how… 🤔)
1. From the DB to the external endpoint
Time
Questions 🤔
Questions 🤔

46. 46
Questions 🤔
- Is it working as expected?
- Will we have to change something?

47. 47
Implement save usage
resources in a repository
Business logic: find all the
services and connect to all of
them, asking for their
resource usage
Change DB model Business logic: list of usage
resources to save
Controller: implement the endpoint
that triggers the sync between all
services
Implement the
repository to save the
resource usage
(guessing how … 🤔 )
Change database
structure
Implement part of the
business logic by
saving a list of usage
resources
(guessing how… 🤔)
Implement the
endpoint that triggers
the synchronization
for all services
1. From the DB to the external endpoint
Time
Retrieve the list of
existing services and
for each one, connect
to it and ask for their
resource usage
Questions 🤔
Questions 🤔
Questions 🤔

48. 48
Questions 🤔
- Is it working as expected?
- Will we have to change something?
(But at least, we can start triggering
something manually 🙂)

49. 49
Implement save usage
resources in a repository
Business logic: find all the
services and connect to all of
them, asking for their
resource usage
Tests for the
repository
Change DB model Business logic: list of usage
resources to save
Controller: implement the endpoint
that triggers the sync between all
services
Implement the
repository to save the
resource usage
(guessing how … 🤔 )
Test if the method we
created for saving
data works as
expected
Change database
structure
Implement part of the
business logic by
saving a list of usage
resources
(guessing how… 🤔)
Implement the
endpoint that triggers
the synchronization
for all services
1. From the DB to the external endpoint
Time
Retrieve the list of
existing services and
for each one, connect
to it and ask for their
resource usage
Questions 🤔
Questions 🤔
Questions 🤔
Questions , but 😅
😅

50. 50
Finally !! 🙂
We are verifying something
is working as expected !

51. 51
Implement save usage
resources in a repository
Business logic: find all the
services and connect to all of
them, asking for their
resource usage
Tests for the
repository
Tests for the business
logic
Change DB model Business logic: list of usage
resources to save
Controller: implement the endpoint
that triggers the sync between all
services
Implement the
repository to save the
resource usage
(guessing how … 🤔 )
Test if the method we
created for saving
data works as
expected
Change database
structure
Implement part of the
business logic by
saving a list of usage
resources
(guessing how… 🤔)
Implement the
endpoint that triggers
the synchronization
for all services
Tests for retrieving all the
information for all the
services.
Tests when something
goes wrong (and probably
add logic around it? 🤔)
1. From the DB to the external endpoint
Time
Retrieve the list of
existing services and
for each one, connect
to it and ask for their
resource usage
Questions 🤔
Questions 🤔
Questions 🤔
Questions , but 😅
😅
Verifying ✅

52. 52
Finally !! 🙂
We are verifying the business logic
is working as expected !

53. 53
Questions araised 🤔
- What we should do here? Should we return
an error and change the methods /
Endpoint?
Questions araised 🤔
- What we should do here? Should we
return an error and change the method
of the Repository?

54. 54
Implement save usage
resources in a repository
Business logic: find all the
services and connect to all of
them, asking for their
resource usage
Tests for the
repository
Tests for the business
logic
Change DB model Business logic: list of usage
resources to save
Controller: implement the endpoint
that triggers the sync between all
services
Implement the
repository to save the
resource usage
(guessing how … 🤔 )
Test if the method we
created for saving
data works as
expected
Change database
structure
Implement part of the
business logic by
saving a list of usage
resources
(guessing how… 🤔)
Implement the
endpoint that triggers
the synchronization
for all services
Tests for retrieving all the
information for all the
services.
Tests when something
goes wrong (and probably
add logic around it? 🤔)
1. From the DB to the external endpoint
Time
Retrieve the list of
existing services and
for each one, connect
to it and ask for their
resource usage
Questions 🤔
Questions 🤔
Questions 🤔
Questions , but 😅
😅
Verifying ✅
Tests for the endpoint
& Acceptance test
Verifying ✅, but changes ? 🤔
Create Acceptance test
to verify that the
entire workflow works
as expected.
Define/implement the
behavior when
something goes
wrong.

55. 55
Finally we closed the loop ! 🔁 🙂
- Created the acceptance
test for the happy path

56. 56
Verifying some of the
wrong scenarios 🙂
What about the
wrong scenarios? 🤔

57. 57
Wait !?
- We found the overall solution does not
work 💥🛑 !? : we're forcing our clients to wait
for the overall process ?!
⏳  timeouts 💥🛑
(going to all the services and check their
resource consumption)
- Redesign ‼
- We will need to think about how to
implement to handle them 🤔.
- Found issues  The final solution is
not working !? 💥🛑
- We will need to change our internal
business logic 🤔 ‼️

58. 58
Implement save usage
resources in a repository
Business logic: find all the
services and connect to all of
them, asking for their
resource usage
Tests for the
repository
Tests for the business
logic
Change DB model Business logic: list of usage
resources to save
Controller: implement the endpoint
that triggers the sync between all
services
Implement the
repository to save the
resource usage
(guessing how … 🤔 )
Test if the method we
created for saving
data works as
expected
Change database
structure
Implement part of the
business logic by
saving a list of usage
resources
(guessing how… 🤔)
Implement the
endpoint that triggers
the synchronization
for all services
Tests for retrieving all the
information for all the
services.
Tests when something
goes wrong (and probably
add logic around it? 🤔)
1. From the DB to the external endpoint
Time
Retrieve the list of
existing services and
for each one, connect
to it and ask for their
resource usage
Questions 🤔
Questions 🤔
Questions 🤔
Questions , but 😅
😅
Verifying ✅
Verifying ✅, but changes ? 🤔
Verifying ✅, closed the loop 🔁
Changes 🤔
Not working 💥🛑  redesign ‼️
Create Acceptance test
to verify that the
entire workflow works
as expected.
Define/implement the
behavior when
something goes
wrong.
Tests for the endpoint
& Acceptance test

59. 59
1. From the DB to the external endpoint
Time
Questions 🤔
Questions 🤔
Questions 🤔
Questions , but 😅
😅
Verifying ✅
Verifying ✅, but changes ? 🤔
Verifying ✅, closed the loop 🔁
Changes 🤔
Not working 💥🛑  redesign ‼️
Implement save usage
resources in a repository
Business logic: find all the
services and connect to all of
them, asking for their
resource usage
Tests for the
repository
Tests for the business
logic
Change DB model Business logic: list of usage
resources to save
Controller: implement the endpoint
that triggers the sync between all
services
Tests for the endpoint
& Acceptance test

60. 1. From the DB to the external
endpoint
60
• It looks like we progressed from the very
beginning…
• Simple process: we knew what we should
do next (normally)
• We could share changes with the team
( git commit and push ) but with
uncertainty ( no tests ).
❓
• Doubts 🤔 to know if we were building
things correctly (building but not testing)

61. 1. From the DB to the external
endpoint
61
• But we couldn’t 🤔 …
• check if the solution was working…
until the end ‼️
🛑
 it wasn’t working 💥  redesign ‼️
• share anything until the end
↩️ 😅
(even with internal users)
• trigger the code as our clients will
▶️
behave
• react to changes 🔁 (feedback-loop)
• see any progress 📶 until the end of the time
(having developed the entire solution)

62. 62
1. From the DB to the
external endpoint
2. From the Business
logic to the DB and
external endpoint
3. From the external
endpoint to the DB
Process
+/- easy to follow,
but with doubts ❓
Solution working Until the end of the time ❌
Share/push code ❓ (no tests)
Trigger the code ❌
React to changes
( feedback-loop )
❌
See the progress
No progress until the end of
the time ❌
Risks of redesign High 🔺
Summary

63. 1. From the DB to the external endpoint
( from the DB  business logic  endpoint )
2. From the process that connects to the services, to the DB and
endpoint
( internal process  to the DB / business logic  endpoint )
3. From the external endpoint that triggers the process, to the DB
( endpoint  business logic  DB )
63
Approaches

64. 64
Business layer Use cases (Services)
Presentation layer Controllers
Repositories
Data access
Storage
DB
2. From the process that connects to the services,
to the DB and endpoint

65. 65
Time
2. From the process that connects to the services,
to the DB and endpoint

66. 66
Business logic: find all the
services and connect to all of
them, asking for their resource
usage
Retrieve the list of
existing services and
for each one, connect
to it and ask for their
resource usage
Time
2. From the process that connects to the services,
to the DB and endpoint

67. 67
Questions 🤔
- What should we do here? How
can we continue? In which way?
- Should we create the methods
we need … and putting this “on
hold” ?
- How should we handle the
errors?
- Will it work as expected?

68. 68
Business logic: list of usage
resources to save
Business logic: find all the
services and connect to all of
them, asking for their resource
usage
Implement part of the
business logic by
saving a list of usage
resources
Retrieve the list of
existing services and
for each one, connect
to it and ask for their
resource usage
2. From the process that connects to the services,
to the DB and endpoint
Questions / “standby” ❓
❓
Questions 🤔
- What should we do here? How can we
continue?
- Should we create the methods we
need … and putting this “on hold” ?
- Will it work as expected?

69. 69
Business logic: list of usage
resources to save
Business logic: find all the
services and connect to all of
them, asking for their resource
usage
Implement save usage resources
in a repository
Implement part of the
business logic by
saving a list of usage
resources
Retrieve the list of
existing services and
for each one, connect
to it and ask for their
resource usage
Implement the
repository to save the
resource usage
Time
2. From the process that connects to the services,
to the DB and endpoint
Questions / “standby” ❓
❓
Questions / “standby” ❓
❓

70. 70
Questions 🤔
- How can we trigger it?
- Will it work as expected?

71. 71
Business logic: list of usage
resources to save
Change DB model
Business logic: find all the
services and connect to all of
them, asking for their resource
usage
Implement save usage resources
in a repository
Implement part of the
business logic by
saving a list of usage
resources
Retrieve the list of
existing services and
for each one, connect
to it and ask for their
resource usage
Implement the
repository to save the
resource usage
Time
Change database
structure
Questions 🤔
2. From the process that connects to the services,
to the DB and endpoint
Questions / “standby” ❓
❓
Questions / “standby” ❓
❓

72. 72
Business logic: list of usage
resources to save
Change DB model
Business logic: find all the
services and connect to all of
them, asking for their resource
usage
Implement save usage resources
in a repository
Controller: implement the endpoint
that triggers the sync between all
services
Implement part of the
business logic by
saving a list of usage
resources
Retrieve the list of
existing services and
for each one, connect
to it and ask for their
resource usage
Implement the
repository to save the
resource usage
Implement the
endpoint that triggers
the synchronization
for all services
Time
Change database
structure
Questions 🤔
2. From the process that connects to the services,
to the DB and endpoint
Questions / “standby” ❓
❓
Questions / “standby” ❓
❓ Questions 🤔

73. 73
Questions 🤔
- Is it working as expected?
- Will we have to change something?
(But at least, we can start triggering
something manually 🙂)

74. 74
Business logic: list of usage
resources to save
Change DB model
Business logic: find all the
services and connect to all of
them, asking for their resource
usage
Implement save usage resources
in a repository
Controller: implement the endpoint
that triggers the sync between all
services
Implement part of the
business logic by
saving a list of usage
resources
Retrieve the list of
existing services and
for each one, connect
to it and ask for their
resource usage
Implement the
repository to save the
resource usage
Implement the
endpoint that triggers
the synchronization
for all services
Time
Change database
structure
Questions 🤔
Questions 🤔
Questions , but 😅
😅
2. From the process that connects to the services,
to the DB and endpoint
Questions / “standby” ❓
❓
Questions / “standby” ❓
❓
This scenario looks familiar … 🤔

75. 75
Implement save usage
resources in a repository
Business logic: find all the
services and connect to all of
them, asking for their
resource usage
Tests for the
repository
Tests for the business
logic
Change DB model Business logic: list of usage
resources to save
Controller: implement the endpoint
that triggers the sync between all
services
Implement the
repository to save the
resource usage
(guessing how … 🤔 )
Test if the method we
created for saving
data works as
expected
Change database
structure
Implement part of the
business logic by
saving a list of usage
resources
(guessing how… 🤔)
Implement the
endpoint that triggers
the synchronization
for all services
Tests for retrieving all the
information for all the
services.
Tests when something
goes wrong (and probably
add logic around it? 🤔)
1. From the DB to the external endpoint
Time
Retrieve the list of
existing services and
for each one, connect
to it and ask for their
resource usage
Questions 🤔
Questions 🤔
Questions 🤔
Questions , but 😅
😅
Verifying ✅
Verifying ✅, but changes ? 🤔
Verifying ✅, closed the loop 🔁
Changes 🤔
Not working 💥🛑  redesign ‼️
Create Acceptance test
to verify that the
entire workflow works
as expected.
Define/implement the
behavior when
something goes
wrong.
Tests for the endpoint
& Acceptance test

76. 76
Business logic: list of usage
resources to save
Change DB model
Tests for the
repository
Tests for the business
logic
Business logic: find all the
services and connect to all of
them, asking for their resource
usage
Implement save usage resources
in a repository
Controller: implement the endpoint
that triggers the sync between all
services
Implement part of the
business logic by
saving a list of usage
resources
Test if the method we
created for saving
data works as
expected
Retrieve the list of
existing services and
for each one, connect
to it and ask for their
resource usage
Implement the
repository to save the
resource usage
Implement the
endpoint that triggers
the synchronization
for all services
Tests for retrieving all the
information for all the
services.
Tests when something
goes wrong (and probably
add logic around it? 🤔)
Time
Change database
structure
Questions 🤔
Questions 🤔
Questions , but 😅
😅
Verifying ✅
Verifying ✅, but changes ? 🤔
Verifying ✅, closed the loop 🔁
Changes 🤔
Not working 💥🛑  redesign ‼️
Create Acceptance test
to verify that the
entire workflow works
as expected.
Define/implement the
behavior when
something goes
wrong.
Tests for the endpoint
& Acceptance test
2. From the process that connects to the services,
to the DB and endpoint
Questions / “standby” ❓
❓
Questions / “standby” ❓
❓

77. 87
Business logic: list of usage
resources to save
Change DB model
Tests for the
repository
Tests for the business
logic
Business logic: find all the
services and connect to all of
them, asking for their resource
usage
Implement save usage resources
in a repository
Controller: implement the endpoint
that triggers the sync between all
services
Implement part of the
business logic by
saving a list of usage
resources
Test if the method we
created for saving
data works as
expected
Retrieve the list of
existing services and
for each one, connect
to it and ask for their
resource usage
Implement the
repository to save the
resource usage
Implement the
endpoint that triggers
the synchronization
for all services
Tests for retrieving all the
information for all the
services.
Tests when something
goes wrong (and probably
add logic around it? 🤔)
Time
Change database
structure
Questions 🤔
Questions 🤔
Questions , but 😅
😅
Verifying ✅
Verifying ✅, but changes ? 🤔
Verifying ✅, closed the loop 🔁
Changes 🤔
Not working 💥🛑  redesign ‼️
Create Acceptance test
to verify that the
entire workflow works
as expected.
Define/implement the
behavior when
something goes
wrong.
Tests for the endpoint
& Acceptance test
2. From the process that connects to the services,
to the DB and endpoint
Questions / “standby” ❓
❓
Questions / “standby” ❓
❓

78. 88
Business logic: list of usage
resources to save
Change DB model
Tests for the
repository
Tests for the business
logic
Business logic: find all the
services and connect to all of
them, asking for their resource
usage
Implement save usage resources
in a repository
Controller: implement the endpoint
that triggers the sync between all
services
Time
Questions 🤔
Questions 🤔
Questions , but 😅
😅
Verifying ✅
Verifying ✅, but changes ? 🤔
Verifying ✅, closed the loop 🔁
Changes 🤔
Not working 💥🛑  redesign ‼️
Tests for the endpoint
& Acceptance test
2. From the process that connects to the services,
to the DB and endpoint
Questions / “standby” ❓
❓
Questions / “standby” ❓
❓

79. 2. From the process that connects to the services, to the DB and endpoint
89
• It seems that starting from the business layer
was not a good idea …
• Process not clear 🤔: we didn’t know what we
should do next ( continue with data access
layer or the external endpoint? )
• Commits in red 🔴 ? (build failure)
• Couldn’t share changes with the team
( git commit, no push )
(even worst than the previous approach)
• Doubts 🤔 to know if we were building things
correctly (building but not testing)

80. 2. From the process that connects to the services, to the DB and endpoint
90
• We couldn’t 🤔 …
• check if the solution was working…
until the end ‼️
🛑
 it wasn’t working 💥  redesign ‼️
• share anything until the end
↩️ 😅
(even less than with the previous approach:
more code dependency)
• trigger the code as our clients will behave
▶️
• react to changes 🔁 (feedback-loop)
• see any progress 📶 until the end of the time
(having developed the entire solution)

81. 91
1. From the DB to the
external endpoint
2. From the Business
logic to the DB and
external endpoint
Process
+/- easy to follow,
but with doubts ❓
Not clear ❌
Solution working Until the end of the time ❌ Until the end of the time ❌
Share/push code ❓ (no tests) ❌
Trigger the code ❌ ❌
React to changes
( feedback-loop )
❌ ❌
See the progress
No progress until the end of
the time ❌
(even less than option 1.) ❌
Risks of redesign High 🔺 High 🔺
Summary

82. 1. From the DB to the external endpoint
( from the DB  business logic  endpoint )
2. From the process that connects to the services, to the DB and endpoint
( internal process  to the DB / business logic  endpoint )
3. From the external endpoint that triggers the process, to the DB
( endpoint  business logic  DB )
92
Approaches

83. 93
Business layer Use cases (Services)
Presentation layer Controllers
Repositories
Data access
Storage
DB
3. From the external endpoint that triggers the process to the
DB

84. 94
Time
3. From the external endpoint that triggers the process to the
DB

85. 95
Test for the Acceptance tests
Emergent / simple design
Create the Acceptance
test.
Design the solution we
expect to build.
Time
3. From the external endpoint that triggers the process to the
DB

86. 96

87. 97

88. 98

89. 99

90. 100

91. 101
Test for the Acceptance tests
Emergent / simple design
Create the Acceptance
test.
Design the solution we
expect to build.
Time
Create the
controller/endpoint
Implement the minimum to
solve the test
Solve the Acceptance
test
Designing and building
‍
3. From the external endpoint that triggers the process to the
DB

92. 102

93. 103

94. 104

95. 105

96. 106
Test for the Acceptance tests
Emergent / simple design
Create the Acceptance
test.
Design the solution we
expect to build.
Time
Create the
controller/endpoint
Implement the minimum to
solve the test
Solve the Acceptance
test
Designing and building
‍
Change DB model
Verifying & sharing
↩ ️
Test for the Business logic: list of
usage resources to save
Create Use Case skeleton
Design how to retrieve
the list of existing
services and for each
one, connect to it and
ask for their resource
usage. Create test for it
3. From the external endpoint that triggers the process to the
DB

97. 107

98. 108

99. 109

100. 110

101. 111

102. 112
Test for the Acceptance tests
Emergent / simple design
Create the Acceptance
test.
Design the solution we
expect to build.
Time
Create the
controller/endpoint
Implement the minimum to
solve the test
Solve the Acceptance
test
Designing and building
‍
Change DB model
Verifying & sharing
↩ ️
Test for the Business logic: list of
usage resources to save
Create Use Case skeleton
Design how to retrieve
the list of existing
services and for each
one, connect to it and
ask for their resource
usage. Create test for it
Designing , building & sharing
‍ ️
Created the Use
Case/Service. Identified
more dependencies.
Created the task that
will do the work in the
background
Implement the
Business Logic
(background task)
Implement the
background task
3. From the external endpoint that triggers the process to the
DB

103. 113

104. 114
Test for the Acceptance tests
Emergent / simple design
Create the Acceptance
test.
Design the solution we
expect to build.
Time
Create the
controller/endpoint
Implement the minimum to
solve the test
Solve the Acceptance
test
Designing and building
‍
Change DB model
Verifying & sharing
↩ ️
Test for the Business logic: list of
usage resources to save
Create Use Case skeleton
Design how to retrieve
the list of existing
services and for each
one, connect to it and
ask for their resource
usage. Create test for it
Designing , building & sharing
‍ ️
Created the Use
Case/Service. Identified
more dependencies.
Created the task that
will do the work in the
background
Implement the
Business Logic
(background task)
Implement the
background task
Building, verifying ✅
& sharing ↩️
Re-run the acceptance test
Implement the IT test and the
Repository
Run the Acceptance test again
and adapt the endpoint that
must trigger the Use Case.
3. From the external endpoint that triggers the process to the
DB

105. 115

106. 116

107. 117

108. 118

109. 119

110. 120
Test for the Acceptance tests
Emergent / simple design
Create the Acceptance
test.
Design the solution we
expect to build.
Time
Create the
controller/endpoint
Implement the minimum to
solve the test
Solve the Acceptance
test
Designing and building
‍
Change DB model
Verifying & sharing
↩ ️
Test for the Business logic: list of
usage resources to save
Create Use Case skeleton
Design how to retrieve
the list of existing
services and for each
one, connect to it and
ask for their resource
usage. Create test for it
Designing , building & sharing
‍ ️
Created the Use
Case/Service. Identified
more dependencies.
Created the task that
will do the work in the
background
Implement the
Business Logic
(background task)
Implement the
background task
Building, verifying ✅
& sharing ↩️
Re-run the acceptance test
Implement the IT test and the
Repository
Build the integration
test for the Repository.
Implement the
repository
Run the Acceptance test again
and adapt the endpoint that
must trigger the Use Case.
Verifying , building & sharing
↩ ️
Implement the
behavior when
something goes
wrong.
Tests for the error
scenarios
3. From the external endpoint that triggers the process to the
DB

111. 121
We already designed
(time ago) how we
will handle them 🙂
What about the
wrong scenarios?

112. 122
Verifying some of the
wrong scenarios 🙂

113. 123
Create the
controller/endpoint
Implement the minimum to
solve the test
Implement the
Business Logic
(background task)
Re-run the acceptance test
Implement the IT test and the
Repository
Test for the Acceptance tests
Emergent / simple design
Test for the Business logic: list of
usage resources to save
Create Use Case skeleton
Solve the Acceptance
test Implement the
background task
Create the Acceptance
test.
Design the solution we
expect to build.
Time
Change DB model
Building, verifying ✅
& sharing ↩️
Implement the
behavior when
something goes
wrong.
Tests for the error
scenarios
Designing and building
‍
Verifying & sharing
↩ ️
Designing , building & sharing
‍ ️
Design how to retrieve
the list of existing
services and for each
one, connect to it and
ask for their resource
usage. Create test for it
Created the Use
Case/Service. Identified
more dependencies.
Created the task that
will do the work in the
background
Building, verifying ✅
& sharing ↩️
Build the integration
test for the Repository.
Implement the
repository
Run the Acceptance test again
and adapt the endpoint that
must trigger the Use Case.
Verifying , building & sharing
↩ ️
3. From the external endpoint that triggers the process to the
DB

114. 124
Create the
controller/endpoint
Implement the minimum to
solve the test
Implement the
Business Logic
(background task)
Re-run the acceptance test
Implement the IT test and the
Repository
Test for the Acceptance tests
Emergent / simple design
Test for the Business logic: list of
usage resources to save
Create Use Case skeleton
Time
Building, verifying & sharing
↩ ️
Tests for the error
scenarios
Designing and building
‍
Verifying & sharing
↩ ️
Designing , building & sharing
‍ ️
Building, verifying & sharing
↩ ️
Verifying , building & sharing
↩ ️
3. From the external endpoint that triggers the process to the
DB

115. 125
• Starting from the external layer to the DB was a good idea 👍
• Easy process 🙂: we knew what we should do next
( run the tests and moving down to the next internal layer )
• commits in red 🔴 ( until we have our feature finished ✅ )
• We could always share changes with the team
( git commit & push ↩️)
• No doubts to know if we were building things correctly
( designing –thanks to tests-  building ✅ )
3. From the external endpoint that triggers the process to the
DB

116. 126
• We could
• check if the solution was working…
from the very beginning ( we were designing since min 0 )
• share everything from the beginning the end 🙂
↩️
( no dependencies )
• trigger the code as our clients will behave
▶️
• react to changes immediately 🔁 (feedback-loop )
• see progress 📶 all the time
3. From the external endpoint that triggers the process to the
DB

117. 127
1. From the DB to the
external endpoint
2. From the Business
logic to the DB and
external endpoint
3. From the external
endpoint to the DB
Process
+/- easy to follow,
but with doubts ❓
Not clear ❌ Easy to follow 👍
Solution working Until the end of the time ❌ Until the end of the time ❌ From the very beginning 👍
Share/push code ❓ (no tests) ❌
Always
(even with commits in 🔴)
Trigger the code ❌ ❌ ✅
React to changes
( feedback-loop )
❌ ❌ ✅
See the progress
No progress until the end of
the time ❌
(even less than option 1.) ❌ ✅
Risks of redesign High 🔺 High 🔺 Low 🔻
Summary

118. Immediate / fast feedback loop
128
• We’d like to react super fast 🏃 to
changes!
• If we have a problem, it is better
to identify it as soon as we can
• We can trigger/activate things
(as our clients will do) !

119. 129
No unnecessary code
• Our tests serves as a guide/reference
• As we specify what we want to build…
• Less things are implemented
because “what if”
• We will build only what we specify
• Ensure that every step we take is in
the right direction
(no step is done without knowing it
is mandatory)

120. Find defects earlier
130
• We can run tests ↩️
• We can recognize faster than
something is not working as
expected
• Tests help as a “tool” to not make
mistakes (safety net )
• We will identify corner cases while
designing our tests and building
code

121. 131
Easier to change the code
• We will be
building/adapting/growing our
safety net constantly
• Our code will be easier to refactor
• Will give us more confidence !

122. Easy process
132
• John is lazy…
• Allows you not having to remember
many things in the head
• No big design up-front
• We want to build <this_use_case>
• Design a test for <this_use_case>
• Solve the test
Implement <this_use_case>
• { Refactor }

123. 133

124. 134

125. Questions?
135
nacho@cougil.com
https://nacho.cougil.com
• icougil.bsky.social
• @icougil
• https://jvm.social/@icougil
This presentation Feedback form