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 😅
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
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
With TDD…

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

16. 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 🙈
It is extremely difficult 😤 to master at it
Yes, TDD has some disadvantages

18. 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
So, … how it is?

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

20. The process

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

22. 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
Pair programming

23. Martin Fowler (concepts)
• https://www.martinfowler.com/bliki/TestDouble.html
• https://martinfowler.com/articles/mocksArentStubs.h
tml
• 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

24. TAKE MY MONEY
AND SHOW ME THE CODE
!

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

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

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

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

29. Warning – Live coding!

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

31. • 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 😉 (your 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

32. Questions?
nacho@cougil.com
https://nacho.cougil.com
@icougil
https://jvm.social/@icoug
il