In this presentation, we will see the benefits of Test-Driven Development (TDD) and we will see how to get started with. It is a simple introduction of this way of developing software, where our software is being developed guided by tests
We will see a bit of history around TDD, what is the main process that we may follow when working with TDD and the rules around it. Of course, we will also review some good habits and practices when applying TDD and see how to do it step by step with a simple Java example
At the end of session, you will have a wider understanding about what is TDD and why it is interesting to master it and you will see some tips and valuable good practices.
Also we will have time to work *by pairs* and write code while having fun playing some katas! Get ready with your favourite IDE/editor to write code and unit tests with our favourite language
===
* Presentation shared at the Barcelona Java Users Group on July 9, 2020:
https://www.barcelonajug.org/2020/06/introduction-to-test-driven-development.html
3. 3Confidential
Whythis session?
• Understand the basics around TDD
• Be able building a software starting with tests
• Enjoy the benefits of building code covered
by tests
• Code a bit (and probably) learn something
new from your colleagues
• … so do not run away please! 😉
4. Confidential 4
NachoCougil
• Senior Software Engineerat Dynatrace
• TDD &cleancode fan
• Founderof the Barcelona Java Users Group &
the Javaand JVMBarcelona Conference (JBCNConf)
• Father, formermountain marathonrunner 😅
@icougil
WhoamI?
5. Confidential 5
• Raise yourhand at anymoment!
• Also, join ourSlack for any questions, suggestions or ideas you mayhave!
• http://bit.ly/slack-bcnjug
Askquestions atanytime,please!
7. 7Confidential
• A bit of history and why
• Process & rules
• Good habits
• Questions?
• Demo / Kata 1
• Pair programming
• Kata 2
• Break
• Kata 3
• Final Recap
Agenda
8. 8Confidential
• A bitof history and why
• Process & rules
• Good habits
• Questions?
• Demo / Kata 1
• Pair programming
• Kata 2
• Kata 3
• Final Recap
Agenda
9. Confidential 9
• Kent Beck “rediscovered” TDD whenwriting first
testing framework SUnitin1994.
“Taketheinputtape,manuallytypeintheoutput
tapeyouexpect, then programuntiltheactual
outputtapematches the expected output.”
• TDD became part of Extreme Programmingbook
in1999.
Abit of history
11. Confidential 11
How it is?
• Youlearnedhow to write code time ago,…and now you’dmay
learn a different way of writing software… Likedriving a
“different” bike
• Youhaveto kindof "break"yourrules and think outsideyour
comfort zone
12. Confidential 12
• A bit of history and why
• Process &rules
• Good habits
• Questions?
• Demo / Kata 1
• Pair programming
• Kata 2
• Kata 3
• Final Recap
Agenda
14. Confidential 14
Focus on building tests first that will help us demonstrate the
behaviour we want.
Wewill start writing tests and we can’t writeverymuchapart
from a unittest. Tests are first class citizens
No overengineering, simple code, simple solution: makethe test
pass
• You are not allowed to writeany production code unless it is to
makea failing unit test pass.
• Youare not allowed to write any more of a unit test than is
sufficient to fail.
• Youare not allowed to write any
more production code than is
sufficient topass the one failing
unit test.
Robert C. Martin
(uncleBob)
Therules
15. Confidential 15
• A bit of history and why
• Process & rules
• Good habits
• Questions?
• Demo / Kata 1
• Pair programming
• Kata 2
• Break
• Kata 3
• Final Recap
Agenda
16. Confidential 16
• Before you write production code,
check that your test is failing 🔴!
• Each test has only 1 reason to fail
• Write the assertion first
Goodhabits
17. Confidential 17
Tests namingconvention
Ending the class name
with Should will “force “
you to start describing
an action for every test
you may create
Describe the
expected
behaviour, not
the internals.
Our tests
should describe
behaviour in
plain english
18. Confidential 18
• Our tests methods will onlydescribe behavior.
Thereforewewill havea better understanding on
what this class does
• Ourtest will bemore clear
• If some tests fails, we can havea look and see
easily which case is failing
• Wedon’t need to get into details on anyparticular
test if wedon’t need it
Theresult will befocusedonthe business
19. Confidential 19
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
20. Confidential 20
• A bit of history and why
• Process & rules
• Good habits
• Questions?
• Demo / Kata 1
• Pair programming
• Kata 2
• Break
• Kata 3
• Final Recap
Agenda
22. Confidential 22
• A bit of history and why
• Process & rules
• Good habits
• Questions?
• Demo/ Kata1
• Pair programming
• Kata 2
• Break
• Kata 3
• Final Recap
Agenda
23. Confidential 23
Demo/ Kata 1:FizzBuzz
• https://kata-log.rocks/fizz-buzz-kata • Write a program that prints one linefor each numberfrom 1 to
100
• For multiples of 3 print Fizzinstead of the number
• For the multiples of 5 print Buzzinstead of thenumber
• For numberswhich are multiples of both 3 and 5
print FizzBuzzinstead of thenumber
25. Confidential 25
• A bit of history and why
• Process & rules
• Good habits
• Questions?
• Demo / Kata 1
• Pair programming
• Kata 2
• Break
• Kata 3
• Final Recap
Agenda
26. Confidential 26
• An ExtremeProgramming(XP)Practicein which2 developersparticipate inone
developmenteffort at one workstation.
• One,the driver,writescode whilethe other, the navigator orobserver,reviewsthe
code as it istyped in. The 2engineersswitchrolesfrequently.
• While reviewing,the observeralso considers the "strategic"direction of the work,
coming up with ideas for improvementsand likelyfuture problemsto address.This is
intended to freethe driverto focus all of their attention on the"tactical" aspectsof
completingthe currenttask, using theobserveras a safety netand guide.
Pair programming
27. Confidential 27
• Theprocess is:
1. One person (A) writes a newtest and verifies that it fails 🔴
2. Theother developer (B) implements the code needed to pass the test ✅
3. (optional) -Theother developer (B) decides to refactor part of the code
4. Theother developer (B) writes thenext test and verifies that it fails 🔴
5. Thefirst developer (A) implements thecode needed to pass thetest ✅
Ping-pongpairprogramming
28. Confidential 28
Thinkaboutcraftmanship
• Be patience, don’t rush.
• Tryto learn as muchas you can from yourcolleague
• No pair pressure -> negotiation for the win!
• Write code youwill be proud of 😃👍
32. Confidential 32
• A bit of history and why
• Process & rules
• Good habits
• Questions?
• Demo / Kata 1
• Pair programming
• Kata2
• Kata 3
• Final Recap
Agenda
33. Confidential 33
Kata2:Leap year
• As a user, I want to know if a yearis a leap yearor not. • All yearsdivisible by400are leap years (so, for example, 2000
was indeed a leap year),
• All yearsdivisible by100but not by 400 are NOTleap years (so,
for example, 1700,1800,and 1900were not leap years, NORwill
2100bea leap year),
• All yearsdivisible by 4but not by100are leap years (e.g., 2008,
2012,2016),
• All yearsnot divisible by4 are NOT leap years (e.g. 2017,2018,
2019).
34. Confidential 34
• A bit of history and why
• Process & rules
• Good habits
• Questions?
• Demo / Kata 1
• Pair programming
• Kata 2
• Kata3
• Final Recap
Agenda
35. Confidential 35
Kata3:String calculator
• Createa simple String calculator with a method signature:
int Add(string numbers)
• Themethod can takeup to two numbers, separated by commas,
and will returntheir sum.
Examples:
• “” or “1” or “1,2” as inputs.
• For an empty string it will return0.
37. Confidential 37
Kata3:String calculator
• Iteration 2
Allow theAdd method to handle newlinesbetween numbers
(instead of commas).
Examples:
• Thefollowing input is ok: “1n2,3”(will equal 6)
• Thefollowing input is NOTok: “1,n” (not need to proveit -just
clarifying)
38. Confidential 38
Kata3:String calculator
• Iteration 3
Support different delimiters:
• To change adelimiter, the beginning ofthe string will contain a
separate line that looks like this: “//[delimiter]n[numbers…]” for
example “//;n1;2” should return three where the default delimiter
is‘;’.
• The firstline is optional. All existing scenarios should still be
supported.
39. Confidential 39
Kata3:String calculator
• Iteration 4
Calling Add with a negative numberwill throw an
exception “negatives not allowed” -and the negative that was
passed.
• If there are multiple negatives, show all of them in the exception
message.
40. Confidential 40
Kata3:String calculator
• Iteration 5
Numbersbigger than 1000should be ignored.
• Ifyou want more,you can playmore!See: https://kata-
log.rocks/string-calculator-kata
Example:
• 2+ 1001= 2
41. Confidential 41
• A bit of history and why
• Process & rules
• Good habits
• Questions?
• Demo / Kata 1
• Pair programming
• Kata 2
• Kata 3
• Final Recap
Agenda
42. Confidential 42
• Martin Fowler (main concepts around testing)
• https://www.martinfowler.com/bliki/TestDouble.html
• https://martinfowler.com/articles/mocksArentStubs.html
• https://martinfowler.com/articles/practical-test-
pyramid.html
• JamesShore(JS practices)
• https://www.youtube.com/user/jdlshore/videos
• Jason Gorman(Java practices)
• https://www.youtube.com/user/parlezuml/videos
Recommendedcontent
43. Confidential 43
• What this yourfirst experience using TDD?
• Was it somehow useful?
• Did youlearn something today?
• Did you enjoythe session?
• Would youlike to haveanother (more advanced) session?
FinalRecap
Nacho - Around 2hs:
Theorical content - 35mins
1st practice (demo) - 15mins
2nd practice (by attendees) – 50’ – 20-25mins
3rd practice (by attendees) – 1:10 – 25-30mins
Final recap – 1:40 - 15-20mins
- share the link of the presentation in the zoom
Around 2hs:
Theorical content - 35mins
1st practice (demo) - 15mins
2nd practice (by attendees) – 50’ – 20-25mins
3rd practice (by attendees) – 1:10 – 25-30mins
Final recap – 1:40 - 15-20mins
Hermann - Kent Beck’s book…
Developed XP during his work at Chrysler
Hermann -
Around 2hs:
Theorical content - 35mins
1st practice (demo) - 15mins
2nd practice (by attendees) – 50’ – 20-25mins
3rd practice (by attendees) – 1:10 – 25-30mins
Final recap – 1:40 - 15-20mins
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
Around 2hs:
Theorical content - 35mins
1st practice (demo) - 15mins
2nd practice (by attendees) – 50’ – 20-25mins
3rd practice (by attendees) – 1:10 – 25-30mins
Final recap – 1:40 - 15-20mins
Nacho -
Nacho -
(copy the image in the Slack Channel ?)
Nacho -
Nacho -
Around 2hs:
Theorical content - 35mins
1st practice (demo) - 15mins
2nd practice (by attendees) – 50’ – 20-25mins
3rd practice (by attendees) – 1:10 – 25-30mins
Final recap – 1:40 - 15-20mins
Nacho -
Nacho - Around 2hs:
Theorical content - 35mins
1st practice (demo) - 15mins
2nd practice (by attendees) – 50’ – 20-25mins
3rd practice (by attendees) – 1:10 – 25-30mins
Final recap – 1:40 - 15-20mins
Nacho – we have to be here at 35 - 40’ as MAXIMUM <<<<
Nacho -
Nacho - Around 2hs:
Theorical content - 35mins
1st practice (demo) - 15mins
2nd practice (by attendees) – 50’ – 20-25mins
3rd practice (by attendees) – 1:10 – 25-30mins
Final recap – 1:40 - 15-20mins
Nacho –
This back-and-forth between test and code, driver and navigator, can offer better/richer feedback when building a system.
Nacho –
(copy the image in the Slack Channel ?)
Nacho -
Nacho -
Nacho -
Nacho -
Hermann – 2hs:
Theorical content - 35mins
1st practice (demo) - 15mins
2nd practice (by attendees) – 50’ – 20-25mins
3rd practice (by attendees) – 1:10 – 25-30mins
Final recap – 1:40 - 15-20mins
Around 2hs:
Theorical content - 35mins
1st practice (demo) - 15mins
2nd practice (by attendees) – 50’ – 20-25mins
3rd practice (by attendees) – 1:10 – 25-30mins
Final recap – 1:40 - 15-20mins
Around 2hs:
Theorical content - 35mins
1st practice (demo) - 15mins
2nd practice (by attendees) – 50’ – 20-25mins
3rd practice (by attendees) – 1:10 – 25-30mins
Final recap – 1:40 - 15-20mins
XP explained – 1st time TDD appeared – nice intro to XP practices
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