Download to read offline
Uploaded byNacho Cougil
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
More Related Content
Similar to How John started to like TDD (instead of hating it) - Talent Arena (March '25)
How John started to like TDD (instead of hating it) - Talent Arena (March '25)
- 1. How John startedto like TDD (instead of hating it) • March, 2025
- 2.
- 3.
- 4.
- 5.
- 6. 6 And at somepoint … 6
- 7.
- 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 camein 10 • Sometimes were… • Interesting • Incompatible • Incomprehensible • Not mature enough • … • Too late
- 11.
- 12.
- 13. Invalid documentation 13 • Outdated •Incorrect • Missing…
- 14. Many things totake 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.
- 16. 16 Building tests wasboring
- 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.
- 19.
- 20.
- 21.
- 22.
- 23. 23 Questions came tohis 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 our mind • To adapt to changes easily • Have a better documentation • Enjoy writing tests
- 24. 24 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)
- 25. Started to grew 25 •Listening more • Reading more books • Practicing • Personal projects • Katas • Writing less “smart” code more “easy to read” code, easy to test code
- 26. 26 Tried to appliedat 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
- 27. 27 Tried to appliedat work… • Couldn’t make it • … ended up causing frustration
- 28.
- 29.
- 30. 30 1 2 3 Specify what you wouldlike 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
- 31.
- 32.
- 33.
- 34. 34 John started touse TDD it, and he found …
- 35. Immediate / fastfeedback 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. 38 Easier to changethe code • 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 • Allowsyou 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 }
- 40.
- 41.
- 42. i Who am I? NachoCougil 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 nacho@cougil.com https://nacho.cougil.com • icougil.bsky.social • @icougil •https://jvm.social/@icougil This presentation Feedback form
- 44.