The document introduces test-driven development (TDD) and provides an overview of its key concepts and practices. TDD combines test-first development and refactoring, using automated tests as a design tool. It describes the basic TDD cycle of writing a failing test, making it pass with the minimum code, and refactoring. Benefits include breaking work into small chunks, avoiding over-engineering, and encouraging loose coupling. Techniques like fake it till you make it and triangulation are presented, along with examples of practicing TDD on a FizzBuzz kata. The importance of practice and learning from experience is emphasized.

1. Introducción práctica a
Test-Driven Development
Software Craftsmanship Alicante

2. Who am I?
• Rubén Antón A.K.A
@rubocoptero
• Crafting code for Flywire
• h4ckademy alumni

3. What’s TDD?

4. TDD is not testing!

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

6. What is TDD?
• XP practice that combines Test-First and
Refactoring
• Tests as a design tool
• KISS
• Baby steps

7. Mantra

8. 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.

9. Why use TDD?

10. 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

11. –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.”

12. Techniques

13. 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;
}

14. 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;
}

15. 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.

16. –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.”

17. Let’s practice…
just a few last things before to start.

18. Rules
• 30 seconds to go from RED to GREEN
• Don’t lose the GREEN in the refactoring phase.
• No debug

19. Good tests
• Imagine the perfect interface for our operation
• Fast
• Independents
• Arrange - Act - Assert
// Arrange
MyProductionClass myProductionClass = new MyProductionClass();
// Act
bool result = myProductionClass.GetBooleanResult();
// Assert
Assert.IsTrue(result);

20. Before you start
• The focus is to practice writing the best code we
can possibly write and challenge ourselves. It is
important to mention that the goal is not to finish
the exercise as soon as posible, but to learn during
the process via the discussion with our partner.
• Do one task at a time. The trick is to learn to work
incrementally.
• Make sure you only test for correct inputs. there is
no need to test for invalid inputs for this kata

21. FizzBuzz
Return “fizz”, “buzz” or “fizzbuzz”.
For a given natural number greater
zero return:
• “fizz” if it is dividable by 3
• “buzz” if it is dividable by 5
• “fizzbuzz” if it is dividable by 3 and
5.
Input Result
1 1
2 2
3 fizz
6 fizz
5 buzz
10 buzz
15 fizzbuzz
30 fizzbuzz

22. FizzBuzz continuation
• A number is "fizz" if it is divisible by 3 or if it has a 3
in it.
• A number is "buzz" if it is divisible by 5 or if it has a
5 in it.

23. Retrospective time
• What difficulties do we found?
• What we have done?
• What we have learnt?

24. TDD economy
• Either you will have to be able to write twice as
many lines per day as before, or write half as many
lines for the same functionality.
• You’ll have to measure and see what effect TDD
has on your own practice.
• Be sure to factor debugging, integrating, and
explaining time into your metrics, though.

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

26. 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
• …

27. Thank you all!