How John started to like TDD (instead of hating it) - Talent Arena (March '25)

John, a typical developer, used to dread writing tests, finding them boring and unnecessary. Test Driven Development (TDD)? Even worse—he couldn’t see how it worked outside of basic exercises. But something clicked. Through his journey, John discovered the magic of writing tests before the production code: fewer bugs, quicker feedback, and cleaner code. Now, he’s hooked and won’t code any other way. This is the story of how TDD turned a skeptic into a believer. 😅

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

---
Presentation shared at Talent Arena '25

Feedback form:
http://tiny.cc/how-john-tdd-feedback

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

2. 2

3. 3

4. 4

5. 5

6. 6 And at some point … 6

7. Lack of testing 7

8. Long-lived branches 8

9. 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” 9

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

11. 11 Adapt to changes

12. 12 Complexity

13. Invalid documentation 13 Outdated Incorrect Missing…

14. Many things to take into account 14 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” …

15. 15 Limited time

16. 16 Building tests was boring

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

18. 18

19. 19

20. 20

21. 21 Same problems again !?

22. 22

23. Questions came to his mind 23 “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 our mind To adapt to changes easily Have a better documentation Enjoy writing tests

24. Learn from others 24 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)

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

26. Tried to applied at work… 26 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

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

28. Until one day… 28

29. 29

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

31. 31 But, generalizing… INPUT PROCESS OUTPUT

32. 32 But, generalizing…

33. 33 But, generalizing… INPUT PROCESS OUTPUT

34. 34 John started to use TDD it, and he found …

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

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

37. Find defects earlier 37 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

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

39. Easy process 39 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 }

40. 40

41. 41

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

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

44. 44