In workshop we coded a kata in Java, starting from a given scaffold, so we could focus on the fundamental steps of TDD. We learned how to practice our TDD skills; how to drive the code and design decisions with tests; how to refactor the code with no fear; how to keep control of design. Lab was organized in 4 sessions of 25 minutes: an intro to TDD, then 2 sessions of coding and the final retrospective for share your feedback.

1. TDD distilled... in Java

2. Notes
● Shared slides are without images because of intellectual rights reasons.
● In conference slides you found images from “The Colour Monster” thanks to Anna
Llenas and Flamboyant Editions
○ http://www.annallenas.com

3. ● Manuela Munaretto
● Agile Dev at Xpeppers
● Mother
● @m_munaretto
● www.xpeppers.com
● manuela.munaretto@xpeppers.
com
● Ivan Lombardi Borgia
● Agile Dev at Xpeppers
● @ivanlombardib
● www.xpeppers.com
● ivan.lombardiborgia@xpeppers.
com
Who are we?

4. ● Sharing is growing
● Give back to the community
Why we are here?

5. Agenda
25’: Welcome and introduction to codelab
5’: Q&A
25’: Session #1
10’: Retrospective
25’: Session #2
20’: Retrospective
5’: Feedback door

6. Distilled

7. The What and The Why
● The What: the mechanics
● The Why: the ideas behind them

8. The What

9. What I mean by TDD
RED
GREEN REFACTOR
The TDD mantra
● RED
● GREEN
● REFACTOR

10. Add a little failing test
You are not allowed to write any production code unless it is to
make a failing unit test pass.

11. Run all tests and fail
You are not allowed to write any more of a unit test than is
sufficient to fail.

12. Make a little change
You are not allowed to write any more production code than is
sufficient to pass the one failing unit test.

13. Run the tests and succeed
If it succeeds, you’re done.

14. Refactor to name concepts
Explicitly name the concepts before you try to eliminate the
duplication.

15. Refactor to remove duplication
Don’t Repeat Yourself: every piece of knowledge must have a
single, unambiguous, authoritative representation within a
system.

16. Write a test list
● A title
● Get things out of your head quickly
● Any example that comes to mind
● Simpler examples
● All the variations

17. What TDD is not
● Traditional Unit Testing
○ After the program has been
written
○ Try to find problem
● A testing technique
○ Unit Testing
○ Stress Testing
○ Smoke Testing
○ Black box Testing

18. The Why

19. RED
● It forces you to really think about what you are going to do.
● There is a big step between hearing the words of a customer
and understanding the meaning.
● It drives the design.

20. GREEN
● Divide et impera.
● Fake it until make it.
● Don't try to implement two things at a time.
● Writing the easy code first makes writing the hard code easy.

21. REFACTOR
● Make it Clean preserving functionalities.
● Keep work focused.
● Permit more aggressive refactorings.
● Complexity on tests reflect complexity on production code.

22. The Code

23. String Calculator
● Simple exercise to focus on basis
● Also experts need to practice basis
https://github.com/xpeppers/tdd-distilled-java

24. The Feedback

25. Retrospective
● What I learned
○ +
○ -
● Actions
● You should not go through the door
without giving some feedback:
○ A scale 1 to 5
○ 1 = very negative
○ 5 = very positive

26. Resources
● Extreme Programming: A gentle introduction
○ http://www.extremeprogramming.org/
● Test-Driven Development: By Example - Kent Beck
○ http://www.amazon.
it/dp/0321146530/ref=cm_sw_r_tw_dp_5rgrwb1F002NJ
● Cunningham & Cunningham, Inc.
○ http://c2.com/

27. Resources
● The World's Best Intro to TDD
○ http://online-training.jbrains.ca/courses/wbitdd-01
● String Calculator
○ http://osherove.com/tdd-kata-1/
● Understanding the 4 rules of simple design
○ https://leanpub.com/4rulesofsimpledesign

28. Resources
● Workflows Of Refactoring
○ http://martinfowler.com/articles/workflowsOfRefactoring
● The Feedback Door
○ https://dzone.com/articles/feedback-door