How John started to like TDD (instead of hating it) (JavaCro, October'25)

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? Ah! And if you think everything will be theoretical, no! Get ready to see code examples with Spring Boot.

PS: Think of John as a random person, as if he was even the speaker of this talk 😉 !

---
Presentation shared at JavaCro, October'25

Feedback form:
https://bit.ly/john-like-tdd-feedback

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

2. 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://mastodon.social/@icougil

3. 3

4. 4

5. 5

6. 6

7. 7 And at some point … 7

8. Lack of testing 8

9. Long-lived branches 9

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. Questions came to his mind 24 “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. Learn from others 25 Started attending meetups… Someone mentioned many practices and concepts that he didn’t kn o w or he couldn’t practice Feedback-loop Simple design Small releases Pair-programming Refactoring Test D r iven Development (TDD)

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

27. Tried to applied at work… 27 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. Tried to applied at work… 28 Couldn’t make it … ended up causing frustration

29. Until one day… 29

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? Red Green Refactor

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. Build a solution that show o n 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) to build an API 36 Let’s see an example 🙂

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

38. 38 https://github.com/icougil/resource_usage

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

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

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

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

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

44. 44 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 🤔 I s it working as expected? no tests at all Will we have to change something? signatures will change?

45. 45 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 🤔 I s it working as expected? Will we have to change something? Questions 🤔

46. 46 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 🤔

47. 47 Questions 🤔 I s it working as expected? Will we have to change something?

48. 48 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 🤔

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

50. 50 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 😅

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

52. 52 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 ✅

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

54. 54 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?

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

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

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

58. 58 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 🤔 ‼️

59. 59 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 🔁 C hanges 🤔 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

60. 60 1. From the DB to the external endpoint Time Questions 🤔 Questions 🤔 Questions 🤔 Questions 🤔, but 😅 Verifying ✅ Verifying ✅, but changes ? 🤔 Verifying ✅, closed the loop 🔁 C hanges 🤔 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

61. 1. From the DB to the external endpoint 61 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 )

62. 1. From the DB to the external endpoint 62 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)

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

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

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

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

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

68. 68 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?

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

70. 70 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” ❓

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

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

73. 73 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 🤔

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

75. 75 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 … 🤔

76. 76 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 🔁 C hanges 🤔 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

77. 77 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 🔁 C hanges 🤔 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. 78 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 🔁 C hanges 🤔 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” ❓

79. 79 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 🔁 C hanges 🤔 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” ❓

80. 2. From the process that connects to the services, to the DB and endpoint 80 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 )

81. 2. From the process that connects to the services, to the DB and endpoint 81 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)

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

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

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

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

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

87. 87

88. 88

89. 89

90. 90

91. 91

92. 92

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

94. 94

95. 95

96. 96

97. 97

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

99. 99

100. 100

101. 101

102. 102

103. 103

104. 104

105. 105

106. 106

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

108. 108

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

110. 110

111. 111

112. 112

113. 113

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

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

116. 116 Verifying some of the wrong scenarios 🙂

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

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

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

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

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

122. Immediate / fast feedback loop 122 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) !

123. 123 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)

124. Find defects earlier 124 We can run tests ↩️ We can recognize faster that 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

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

126. Easy process 126 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> D esign a test for <this_use_case> Solve the test Implement <this_use_case> { Refactor }

127. 127

128. 128

129. Questions? 129 [email protected] https://nacho.cougil.com icougil.bsky.social @ icougil https://mastodon.social/@icougil This presentation Feedback form