Test Driven Development

Test Driven Development (TDD)

Denis Lutz, Dec 2008

Denis Lutz, 2009

Agenda

Test Driven Development

Agenda 1. Learning the TDD Process 2. Waterfall vs. TDD Process 3. Short-term advantages 4. Long-term advantages 5. Common critics and answers

Denis Lutz, 2009

TDD Formula

Test Driven Development

1. add a test

2. get it to fail

JUnit

JUnit

4. improve design through refactoring

3. write enough code to pass the test

Denis Lutz, 2009

Test Driven Development

User Story
Role: Feature: Business Value: As a user I want to be able to create my shopping cart with products So that I can estimate my costs and buy my products

Denis Lutz, 2009

Test Driven Development

1. add a test...

Denis Lutz, 2009

Test Driven Development

Mac Shortcut: CMD + 1 Windows Shortcut: Win + 1

2. get it to fail...

Denis Lutz, 2009

Test Driven Development

3. write code to pass the test...

... in the simplest possible way

JUnit

Denis Lutz, 2009

Test Driven Development

4. improve design
too simple in this case, later...

Denis Lutz, 2009

TDD Formula

Test Driven Development

Start the loop again....

1. add a test

2. get it to fail

JUnit

JUnit

4. improve design through refactoring

3. write enough code to pass the test

Denis Lutz, 2009

Test Driven Development

1. add a test...
think about the new API before it will be created

Denis Lutz, 2009

2. get the test to fail...

Test Driven Development

Generate now the new missing classes and methods

Denis Lutz, 2009

Test Driven Development

3. write just enough code to pass the test...

JUnit

Denis Lutz, 2009

Test Driven Development

JUnit

JUnit

by switching from a red bar to a green one, we tested our test itself we fulfilled the test through last implementation
Denis Lutz, 2009

Test Driven Development

4. improve design
any change
JUnit

evolve your design create only needed abstractions be always sure the code is still
working

Denis Lutz, 2009

Test Driven Development

Start the loop again....

1. add a test

2. get it to fail

JUnit

JUnit

4. improve design through refactoring

3. write enough code to pass the test

Denis Lutz, 2009

Test Driven Development

1. add a test...

motivate the next new feature by a test!

Denis Lutz, 2009

Test Driven Development

2. get it to fail...
Mac Shortcut: CMD + 1 Windows Shortcut: Win + 1

Denis Lutz, 2009

Test Driven Development

2. get it to fail...

JUnit
Denis Lutz, 2009

Test Driven Development

3. write code to pass the test...

... in the simplest possible way

JUnit
Denis Lutz, 2009

Test Driven Development

4. improve design
always supporting your steps by the test, stay green

JUnit

Denis Lutz, 2009

Classical waterfall process

Test Driven Development

Analysis

Customer Project Manager

A new feature or a small library

Design

What?

Architect Senior Developer

How?

Implementation

Developer

Test

Developer Tester

Denis Lutz, 2009

The process resulting from TDD

Test Driven Development

Analysis

=
1. add a test

Test

What?

2. get it to fail

JUnit

JUnit

4. improve design Design

How?
3. write code to pass the test Implementation

Denis Lutz, 2009

TDD vs Waterfall

Test Driven Development

Waterfall:

Analysis

Design

GAP Formal language lack

TDD:
ShoppingCart .... ...shouldHaveAListOfProductsInsideItself ...shouldCalculateTheSubotalOfAllProductsInTheShoppingCa rt Behavior Driven Development (last evolvement TDD) is binding the user stories directly to the tests!

Denis Lutz, 2009

TDD vs Waterfall

Test Driven Development

Waterfall:

predict the right design (M.Fowler, Is design dead?) think about everything upfront? sit down and think where to start, make random
drafts

Design

TDD:
dont think about the design in detail (at class level) adapt your design to your needs later, create the abstractions you will only
need

let your design evolve with time change the design fast alway assured by the tests

Denis Lutz, 2009

TDD vs Waterfall

Test Driven Development

Waterfall:

fullfill the planned design in anycase or develop without any plan danger to develop things you will not need at the end trying to get classes work somehow together at the end

Implementation

TDD:

Denis Lutz, 2009

develop only what needed dont really think about the design upfront get motivated and driven by the test try to close the loop to green as fast as possible make changes to former code without any concern that you break it

TDD vs Waterfall
Analysis Design Implementation Test

Test Driven Development

Waterfall testing:
hope to have no bugs, creating ad-hoc and random test cases since the code is not test friendly => time consuming and of bad test quality
(testing of huge private methods after they are written)

boring task, trying to finish it fast already lost time with manual testing will debug the code you wrote days or weeks ago or even not your code might be removed with more project pressure

TDD: Your test is already done!

Denis Lutz, 2009

TDD vs Waterfall Analysi s

Test Driven Development

Test

Is a test still a test ?

We should consider the test as specification of our requirements!
ShoppingCart .... ...shouldHaveAListOfProductsInsideItself ...shouldCalculateTheSubotalOfAllProductsInTheShoppingCa rt

Behavior Driven Development (BDD) by Dan North Large adoption in the rails community with RSpec
Denis Lutz, 2009

Short-term advantages

Test Driven Development

Short-term advantages

by writing the test first we are able to think about the API and create it user friendly we did not try to achieve the planned design, which is a hard task we never thought about design, just started to develop we immediately created an executable specification for our code the code is born with two clients: the test using it and the client code => reusable code

avoid loosing the time by build process, build and deploy only if everything is tested compiler is assuring the syntax, tests assuring semantics write the test once and develop against it, never check things manually for their
correctness

Denis Lutz, 2009

Long term advantages

Test Driven Development

Long term advantages

agressive refactoring possible through high test coverage => fast reaction on change => agility we will face more bugs upfront and avoid debugging in the future, which is one of the most
consuming time tasks, if the code was written long time ago

reduce the debugging by QA, which is much more time intensive as by developer continuos integration can only be based on a good test suite, TDD is the perfect
base for it

Denis Lutz, 2009

Test Driven Development

Long term advantages

tests will enforce compositions oriented design this correlates very well with dependency injection of spring stubbing can be easily realized, making the test faster and independent
Main Service

DAO

external Tax-Service

Validation Service

<<implements>>

<<implements>> Stub Implementation

<<implements>>

DAOImpl
Denis Lutz, 2009

ValidationServiceImlpl

Pro and Contra, decide yourself....

Test Driven Development

Time Invest into TDD and Maintenance of Tests VS

Long term
invasive refactoring possible through high test coverage => fast reaction on change =>
agility

Short term

by writing the test first we are able to think about the API and create it user friendly we did not try to achieve the planned design, which is a hard task we never thought about design, just started to develop we immediately created an executable specification for our code the code is born with two clients: the test using it and the client code => reusable code

simpler APIs for other team members the new code was used by the test itself we will face more bugs upfront and avoid debugging in the future, which is one of the most
consuming time tasks, if the code was written long time ago. Author himself can solve the bugs much faster since he has still the code in its mind

reduce the debugging by QA, which is much more time intensive as by developer tests will enforce compositions oriented design this correlates very well with dependency injection of spring stubbing can be easily realized, making the test much faster

avoid loosing the time by build process, build and deploy only if everything is tested compiler is assuring the syntax, tests assuring semantics write the test once and develop against it, never check things manually for their
correctness

Denis Lutz, 2009

Test Driven Development

Testing upfront takes to much time

of not testable code? of course... at the end you have to test your code anyway have you counted your time spent on manual testing during
development?

Why to write tests for code I may be not use

this is only true for a prototype development or a not modularized code

Denis Lutz, 2009

Test Driven Development

Thanks!

Denis Lutz, 2009