This document provides an overview of test driven development (TDD). It explains that TDD is a technique for designing and developing software based on three pillars: implementing exact functionality, reducing defects, and producing modular reusable code. It describes the TDD process of red-green-refactor cycles and writing tests first to define requirements and drive code development. An example problem of validating emails is used to demonstrate TDD in action through iterative test writing and code changes. Key aspects of TDD like test frameworks, the testing algorithm, and end goals are summarized.

1. Test Driven
Development

2. Test Driven
Development
 Technique to design and develop software.
 Practice part of the Extreme Programming methodology — XP
 Based on three fundamental pillars.

3. TheThree
Pillars
 Implement the exact
functionality of the software.
 Reduce the number of defects
on the software – good quality
software
 Produce modular and highly
reusable software.

4. When Doing
TDD
 It’s not about just writing tests.
 Translate use cases to examples.
 Enough to describe the functionality without ambiguity.
 Architecture will eventually emerge.

5. TheTDD
Algorithm
Red
GreenRefactor

6. TheTDD
Algorithm
Red
GreenRefactor

7. TDD InAction
With an example ;-)

8. The Problem Email validation mechanism

9. The Problem
Email validation mechanism

10. The Problem
Email validation mechanism
Neither empty nor null.
Has to contain an @ symbol
Has to belong to the .com, .net and .eduTDLs
Domain part can’t be 1 character long
All lowercase
Not contain numbers
Only _ . - symbols

11. Before we
begin
WritingTests
 Testing framework
 Part of the language
 Ruby
 Rust
 Go
 Python
 External tools and libraries
TestNG
MSTest

12. Neither empty nor null
Red
@Test
public void shouldReturnFalseIfEmailIsNull() {
String email = null;
EmailValidator validator = new EmailValidator();
boolean isValid = validator.isValid(email);
assertThat(isValid, equalTo(false));
}

13. Neither empty nor null
Green public boolean isValid(String email) {
return false;
}

14. Neither empty nor null
Red
@Test
public void shouldReturnTrueIfEmailLengthIsGreaterThanZero() {
String email = "some@email.com";
EmailValidator validator = new EmailValidator();
boolean isValid = validator.isValid(email);
assertThat(isValid, equalTo(true));
}

15. Neither empty nor null
Green
public boolean isValid(String email) {
if (email == null) {
return false;
}
return email.length() > 0;
}

16. Contains an @ symbol
Red
@Test
public void shouldReturnFalseIfEmailDoesntContainAtSymbol () {
String email = "someemail.com";
EmailValidator validator = new EmailValidator();
boolean isValid = validator.isValid(email);
assertThat(isValid, equalTo(false));
}

17. Neither empty nor null
Green
public boolean isValid(String email) {
if (email == null) {
return false;
}
if (!email.contains("@")) {
return false;
}
return email.length() > 0;
}

18. Refactor
private EmailValidator validator;
@Before
public void setUp () {
validator = new EmailValidator();
}

19. In the end…
 Components will behave exactly as we want.
 Tests will be the documentation of our system.
 Tests will break if changes compromise the system.

20. Thank you!
Carlos Andrés Oquendo
coquendo@thoughtworks.com
@andres19_05