Have you heard of TDD? Are you interested or familiar with this practice but have never been able to understand it?
Join this session to see the benefits of Test-Driven Development (TDD), understand how it works and its benefits. In a more detailed approach, we will see this way of developing software, where our code is always built guided by tests.
We will go over some history about TDD, which is the main process we must follow when we work with this mechanic and the rules that surround it. We will also list the main advantages and disadvantages that most developers who practice TDD find and whether the arguments in favour add up to more than those that subtract. Finally, we will review some good habits and practices when applying TDD and see how to do it step by step with an example of a "live" coding session with Java.
At the end of the session, I hope that you will have a wider understanding of what TDD is, what advantages it brings, why it is interesting to master it and also that you will take with you some tricks and good practices to be able to apply them in your day-to-day life when writing code
---
Presentation shared at Trójmiasto Java User Group
Public group 17th of May '23
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 Java and JVM
Barcelona Conference
( JBCNConf DevBcn )
• Java Champion
• Father, former mountain marathon
runner 😅
Who am I?
7. • Where it cames from?
• Advantages &
disadvantages
• Process
• Good habits
• Example
• Final Recap
Agenda
8. • Where it cames from?
• Advantages &
disadvantages
• Process
• Good habits
• Example
• Final Recap
Agenda
9. 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
A bit of history
10. Mockist (London)
• Entry point: acceptance test
• Design from top down
• Main focus on the
interactions between the
components of our solution
• Focus on messages we will
use with our classes. Here is
where mock objects appear
Classical (Chicago)
• Described by Kent Beck
• More emphasis on “discovering” the
internals of our code mainly by
refactoring
• The structure of our classes and
modules emerges as we evolve our
code (ex: removing duplication,
encapsulation, etc)
• Focused on changes in an state or
return values from functions
Two TDD
schools
11.
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 ✅
Imagine…
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)
Imagine…
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 🙈
It is extremely difficult 😤 to master at it
Yes, TDD has some disadvantages
16.
17. 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?
18. To be used in your design &
coding process , for
building better modularized
and tested software
And, what does it
seek?
19. • Where it cames from?
• Advantages &
disadvantages
• Process
• Good habits
• Example
• Final Recap
Agenda
21. • Where it cames from?
• Advantages &
disadvantages
• Process
• Good habits
• Example
• Final Recap
Agenda
22. 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
23. 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
24. 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
25. Before you write production code,
check 👀 that your test is failing 🔴
Each test has only 1 reason to fail
Write the assertion first
Technical 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. • Where it cames from?
• Advantages &
disadvantages
• Process
• Good habits
• Example
• Final Recap
Agenda
31. 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
32. • Where it cames from?
• Advantages &
disadvantages
• Process
• Good habits
• Example
• Final Recap
Agenda
33. • 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
“Take the input tape, manually type in the output tape you expect, then program until the actual output tape matches the expected output.”
VS create tests after…
IEEE = ai triple i
IEEE: case study at IBM 2003 – 40% fewer defects when using TDD
The art of fearless: increased effort and/or quality effect (from IEEE) -- good collection of articles and empirical studies on TDD both in private companies and in the academic world
- Forget : especially if you are not in an environment / team that does not encourage its use or you cannot experiment with it comfortably
- Having a high level of coverage is an indirect consequence of using/applying TDD
You have to kind of "break" your rules and think outside your comfort zone
Specify what you want to code to do
Create just enough code to satisfy the desired behaviour (just make it work!)
Clean your code and test / remove duplication / make it better
>>>> Focus on building tests 1st that will help us demonstrate the behaviour we want.
>>>> We will start writing tests and WE CAN’T WRITE VERY MUCH APART FORM A UNIT TEST. Tests are 1ST class citizens
>>>>> No overengineering, simple code, simple solution: MAKE THE TEST PASSS!!!
-> min 10-11'
This back-and-forth between test and code, driver and navigator, can offer better/richer feedback when building a system.
This is intended to free the driver to focus all of their attention on the "tactical" aspects of completing the current task, using the observer as a safety net and guide.
GOOST >> TDD learn, understand & apply
TDD by example – basic intro, idealised situation…
The art of unit testing – easy to read
TDD a practical guide – some examples with GUI & real examples
