TDD - Seriously, try it - Codemotion (May '24)

Ever wondered about the wonders of Test-Driven Development (TDD)? Curious devs, this session is for you!
Get ready to dive into TDD and explore its benefits. We'll see the "secrets" behind TDD, its roots, and the rules surrounding it. But that's not all! We'll also uncover the ups and downs of TDD, plus we'll share some tips and tricks... including a live coding session in Java. Get ready to level up your development skills with TDD – more insights, more advantages, and more confidence in your coding adventures!

PS: Building tests before production code can sound more fun than it sounds 😉.

---
Presentation shared at Codemotion Madrid '24

Feedback form:
https://bit.ly/tdd-seriously-try-it-feedback

1. May 22nd, 2024 TDD: seriously, try it  ! 😃  

2. How many of you know what TDD is ? And how many of you practice TDD in your day-to-day job?

3. Review the basics around TDD Understand the benefits of building code designed by tests ( VS building the tests after we write our code ) (I hope) learn some tips See a { live coding } example … so do not run away, please! 😉 Why this session?

4. 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 https:// jvm.social /@ icougil Who am I?

5. Raise your hand at any moment! Ask questions at any time, please!

6. Based on my *personal* experience Warning

7. How can we, developers, sleep peacefully? how can we sleep without fear that something fails badly, and we must wake up in the middle of the night because something has failed ?

8. Thanks to tests! ❤️🤩

9. But testing is boring! … isn’t it?

10. How can we design (and deliver) software in such a way that we can deliver portions incrementally ? With parts that provide value and be confident that they are OK / bug-free ? ( or at least we handle some error cases ) ?

11. Kent Beck “ rediscovered ” TDD when writing first testing framework SUnit in 1994. TDD became part of eXtreme Programming (XP) book in 2000. Developed XP during his work at Chrysler The book Test-Driven Development by Example was published in 2002 The history

12. … you follow a simple process ⚙️ that helps you to design and develop your software in a straightforward way … you can find defects earlier ⏱ (when running or designing your tests) … you can easily detect regression errors 🔴 … your software is going to be easier to refactor because of a safety net ✅ With TDD…

13. ... your software guides you how a consumer will use your component ⏛ … tests are living documentation (really 🖖 !!) … the software you write it is likely to have less bugs 🐛 … your development costs 💰 will be lower References: - Test-driven development as a defect-reduction practice (IEEE) - Guest Editors' Introduction: TDD--The Art of Fearless Programming (computer.org) With TDD…

14. It is not so easy to start with 😅 (not many good places to help, majority of people are not using it daily) Has a high learning curve 😟 (depends directly on the complexity of your code + your design and engineering capabilities) Can be a large investment 💸 in a team (depending on the experience of the members + requires time ⏳ & effort 🙇‍♀️🙇‍♂️) Yes, TDD has some disadvantages

15. It is really easy to forget 😓 about it It provokes resistance ☹️ (in some people ⚔️) Can be corrupted and lead to the syndrome of reaching the highest possible level of coverage 🙈 I t is extremely difficult 😤 to master at it Yes, TDD has some disadvantages

16. You learned how to write code time ago,… …and now you’d may learn a different way of writing software. Like “ learning to ride a very different bike” ,... but being older 😅 So, … how it is?

17. To be used in your design & coding process , for building better modularized and tested software And, what does it seek?

18. The process

19. Start little by little: katas, POCs, personal projects, ... Practice... ... and keep practicing ... and keep on ... until you finally internalise it 🧘‍♀️😉 Practice with somebody else ( pair-programming ) Keep learning: online content, books, ... Learn and practice

20. An  Extreme Programming (XP) Practice in which 2 developers participate in one development effort at one workstation. One, the  driver , writes code  while the other, the  navigator or observer , reviews the code as it is typed in. The 2 engineers switch roles frequently.   While reviewing, the observer also considers the " strategic " direction of the work, coming up with ideas for improvements and likely future problems to address. Pair programming

21. Martin Fowler (concepts) https://www.martinfowler.com/bliki/TestDouble.html https://martinfowler.com/articles/mocksArentStubs.html https://martinfowler.com/articles/practical-test-pyramid.html Dave Farley (CI, TDD, etc) https://www.youtube.com/ContinuousDelivery/ James Shore (TDD series) https://www.youtube.com/jdlshore/ Jason Gorman (Java Code Craft) https://www.youtube.com/parlezuml/ Recommended content

22. TAKE MY MONEY AND SHOW ME THE CODE !

23. Before you write production code, check 👀 that your test is failing 🔴 Each test has only 1 reason to fail Write the assertion first Some good habits

24. Tests naming convention Describe the expected behaviour, not the internals. Our tests should describe behaviour in plain english E nding the class name with Should will “force “ you to start describing an action for every test you may create

25. Our tests methods will only describe behavior . Therefore, we will have a better understanding on what this class does Our tests will be more clear If some tests fails, we can have a look and see easily which case is failing We don’t need to get into details on any test to understand what are they pursuing The result will be focused on the business

26. Test creation order 1) Name the class 2) Name the method 3) Define what you want to check 4) Trigger the code 5) Do the setup

27. Warning – Live coding!

28. Requirements : Build a service that returns a list of films that are associated with a particular genre By default, the result must be ordered according to the average rating given to the films by the users A film should contain at least an id, title a year when it was published, one or more tags and one or more genres Example: recommendationService.filmsByGenre (”science-fiction”) https://github.com/icougil/FilmRecommendationService We have just started working in a startup that sells and rents out films over the Internet Our product managers have told us that they want to add new functionalities by building a service that allows them to recommend films to the users of the current platform. Kata: Film Recommendation Service

29. TDD helps you to design & develop your code in a simple and effective way (better modular design) 👌 It is difficult to adapt to its mechanics and sometimes is difficult 😅 to maintain its practice... It worth a try 😉 ( y our software will have less bugs 🐛 & it will be easier to maintain 💰) There are some tips 💡 ( could make your life easier ) Try to pair , it will help 😃 you ( a lot ) Practice , practice & practice 🥋 again Final Recap

30. Questions? [email protected] https://nacho.cougil.com @ icougil https:// jvm.social /@ icougil