Presentación realizada en el meetup Software Craftsmanship Alicante el 31/10/2018.

1. Software Craftsmanship
Alicante

2. Introducción a Test-
Driven Development
Software Craftsmanship Alicante

3. Who am I?
• Rubén Antón A.K.A
@rubocoptero
• TDD infected

4. Today's session
• Theoretical introduction
• Kata Bowling application

5. What’s TDD?

6. TDD is not testing!

7. Mantra

8. eXtreme Programming (XP)
by Kent Beck

9. Values
• Communication
• Simplicity
• Feedback
• Courage
• Respect

10. Some principles
• Humanity
• Economics
• Mutual Benefit
• Self-Similarity
• Improvement
• Flow
• Quality
• Baby Steps

11. Test-First Programming
• Write a failing automated test before adding
functionality.
• Many problems addressed:
• Scope creep
• Coupling and cohesion
• Trust
• Rhythm

12. Incremental Design
• Minimize design investment over the short run.
• Keep it in proportion to the needs of the system.
• Design done close to when it is used is more
efficient.
• Simple heuristic: Eliminate duplication.

13. Goal
• Create conditions under which the cost of
changing the software doesn't rise catastrophically.

14. Two simple rules
• Don’t write a line of new code unless you first have
a failing automated test.
• Eliminate duplication.

15. Mantra

16. Steps
1. ROJO: write a little test that doesn’t work, perhaps
doesn’t even compile at first
2. GREEN: make the test work quickly, committing
whatever sins necessary in the process
3. REFACTOR: eliminate all the duplication created
in just getting the test to work.

17. Why use TDD?

18. Benefits
• Manually verification is time consuming
• Break down our work into manageable chunks
• Source of documentation
• Avoid over-engineering
• Safety net
• Encourages Loosely Coupled Design

19. –Chris Jordan
“Software is inherently complex, and being able
to make things easier for ourselves as
developers is a crucial part of our role to deliver
high quality software.”

20. Techniques

21. Fake it (’til you make it)
1. Return a constant to make it pass
2. Gradually replace constants with variables until
you have the real code
[TestMethod]
public void TestSum()
{
Assert.Equals(4, Sum(3, 1));
}
private int Sum(int x, int y)
{
return 4
}
[TestMethod]
public void TestSum()
{
Assert.Equals(4, Sum(3, 1));
}
private int Sum(int x, int y)
{
return 3 + 1;
}
[TestMethod]
public void TestSum()
{
Assert.Equals(4, Sum(3, 1));
Assert.Equals(5, Sum(3, 2));
}
private int Sum(int x, int y)
{
return x + y;
}

22. Triangulation
• Use two or three test cases before to generalize.
• Only use it when completely unsure of how to refactor.
• What axes of variability are you trying to support in
your design?
[TestMethod]
public void TestSum()
{
Assert.Equals(4, Sum(3, 1));
}
private int Sum(int x, int y)
{
return 4
}
[TestMethod]
public void TestSum()
{
Assert.Equals(4, Sum(3, 1));
Assert.Equals(5, Sum(3, 2));
}
private int Sum(int x, int y)
{
return x + y;
}
[TestMethod]
public void TestSum()
{
Assert.Equals(4, Sum(3, 1));
Assert.Equals(5, Sum(3, 2));
}
private int Sum(int x, int y)
{
return x + y;
}

23. Obvious Implementation
• Fake it and Triangulation use baby steps.
• If you think it’s obvious, type in the real
implementation.
• It’s a "second gear".
• If you get an unexpected red bar, back up.

24. –Kent Beck
“Remember, TDD is not about taking teensy tiny
steps, it’s about being able to take teensy tiny
steps. Would I code day-to-day with steps this
small? No. But when things get the least bit
weird, I’m glad I can.”

25. Some Good Practices
• Keep it green
• Plan the tests beforehand
• Use a notebook
• Work around cohesive units
• Create space for the business logic

26. Let's see it in action...
Bowling Kata

27. More than TDD
• Extreme Programming
practices
• SOLID
• Clean Code
• 4 rules of simple design

28. How can I learn it?
• Practice, practice and practice!
• Read good books
• TDD by example - Kent Beck
• Clean Code - Uncle Bob
• Refactoring - Martin Fowler
• Test Driven - Lasse Koskela
• …

29. Global Day of Coderetreat
Saturday, November 17 from 9:00 to 18:00

30. Thank you all!