The document discusses test-driven development (TDD) and refactoring. It explains what TDD is, how to implement it in three steps - writing a failing test, making the test pass, and refactoring code - and provides an example of modeling a calendar to track holidays using TDD. The document also discusses benefits of TDD like catching mistakes early, increasing coding confidence, and making it easier to implement new requirements through refactoring.

1. agile software development & services
TDD & Refactoring
www.10pines.com
Hernán Wilkinson
Twitter: @HernanWilkinson
www.10pines.com
Classes: university.10pines.com

2. Software

3. Computable Model of a Problem
Domain

4. How do you build a Model?
As a car? As a house?
(is build the right word?)

5. Growing a Model is a “learning
process”

6. “Constructivism”

7. “Constructivism” in our field
https://worrydream.com - https://vimeo.com/36579366

8. ▶ Iterative
▶ Incremental
▶ Immediate Feedback
How

9. What’s TDD?

10. Is it this?

11. What no How!

12. ▶ A learning technique
– Iterative
– Incremental
– With Immediate Feedback
▶ Side effects
– Remembers all we learned
– Tells us as soon we make a mistake
What TDD is

13. ▶ It is not testing only
▶ It is not “unit testing” only
– Unit tests are one type of test you can
write when doing TDD
What TDD is not

14. ▶ When building/learning
▶ When not:
– Configuring framework (ex. Hibernate)
– Building visual part of UI
When to and When not to?

15. How to do TDD?
1) Write a test
- It has to be the simplest one
- Must fail the firt time it is run

16. 1) Write a test
- It has to be the simplest one
- Must fail the firt time it is run
2) Run all tests
- Implement the simples solution that will
make the test/s pass
- GOTO 2 until all test pass
How to do TDD?

17. 1) Write a test
- It has to be the simplest one
- Must fail the firt time it is run
2) Run all tests
- Implement the simples solution that will
make the test/s pass
- GOTO 2 until all test pass
3) Reflect – Can we have a better impl./design?
- Yes -> Refactor. GOTO 2
- No -> GOTO 1
How to do TDD?

18. 1) Write a test
- It has to be the simplest one
- Must fail the firt time it is run
2) Run all tests
- Implement the simples solution that will
make the test/s pass
- GOTO 2 until all test pass
3) Reflect – Can we have a better impl./design?
- Yes -> Refactor. GOTO 2
- No -> GOTO 1
How to do TDD?

19. 1) Write a test
- It has to be the simplest one
- Must fail the firt time it is run
2) Run all tests
- Implement the simples solution that will
make the test/s pass
- GOTO 2 until all test pass
3) Reflect – Can we have a better impl./design?
- Yes -> Refactor. GOTO 2
- No -> GOTO 1
How to do TDD?

20. 1) Write a test
- It has to be the simplest one
- Must fail the firt time it is run
2) Run all tests
- Implement the simples solution that will
make the test/s pass
- GOTO 2 until all test pass
3) Reflect – Can we have a better impl./design?
- Yes -> Refactor. GOTO 2
- No -> GOTO 1
How to do TDD?

21. 1) Write a test
- It has to be the simplest one
- Must fail the firt time it is run
2) Run all tests
- Implement the simples solution that will
make the test/s pass
- GOTO 2 until all test pass
3) Reflect – Can we have a better impl./design?
- Yes -> Refactor. GOTO 2
- No -> GOTO 1
How to do TDD?

22. Test structure
Setup
Exercise
Assert
Creates the test’s context
Exercises the functionality that is being
tested. Defines WHAT is being tested
Verifies that happened what it was
expected to happend or fails otherwise

23. Example
▶ Model a Calendar where days can be mark as holidays.
Given a date it should be able to know if it is a holiday or
not
▶ Holidays can be defined using:
– A day of week, ex. Sunday
– A day of month, ex. December 25th
– A specific date, ex. 4/20/2012

24. Conclusion - Design
It is difficult to name things
 It is because we do not know enough knowledge!
 Do not spend to much time at the beginning
 Use “Meaningless names” instead of “Bad Names” until
you get enough knowledge

25. Conclusion - Design
It is a continuos learning process
 With time we gained more knowledge about the problem
 We could use better names
 We refactor the code and improve the design

26. Conclusion - Design
 Implement only what you are testing
 Avoid “Analysis Paralysis”

27. Conclusion - Technique
Write the assertions first
Assert negative cases, not only positive
ones
Write one test per functional case (it
does not implies one assertion!)
It is a bad smell when test does not
fails on first run

28. Conclusion - Impact
TDD allow us to have something running
very fast
It’s woking!  Strong psychological effect

29. Conclusion - Impact
We got a fail inmdiatly after making a
mistake!
It give us confidence on our code

30. New requirement!
 Weekday and MonthDay holidays can be
defined in an interval:
From 2/8/2002 to 1/31/2018, April 3rd is
holiday
From 1/1/1990 al 12/31/1999 Mondays are
holiday

31. How do we solve it?
Should we continue with the same
design idea?

34. Let’s do it!

35. Conclusion - Design
 The code speaks to us!
The previous solution did not scale
We made it coping and pasting

36. Conclusion - Design
 The new solution implies a big “conceptual
jump”
Not everybody knows how to do it
That is what we teach in our classes 

37. Conclusion - Design
 TDD does not implies good design
 Good design is made by good designers!

38. Conclusion - Impact
 We implemented a new requirement
without loosing quality
 We made a big refactoring!
… and we were not afraid of doing it
… and we could be sure we did not
break anything

39. Conclusion - Impact
 TDD give us COURAGE to make changes
 TDD help us to avoid the “legacy system”

40. And remember…

41. agile software development & services
Thanks!
info@10pines.com
www.10Pines.com
University.10pines.com
twitter: @10Pines
Twitter: @hernanwilkinson
Argentina
Tel.: +54 (11) 6091-3125
Av. Alem 896, 6to
(1001) Buenos Aires