test driven development by denis lutz

Test Driven Development

Test Driven Development(TDD)

Todays Forum Topic:


Agenda

1. Learning the TDD Process

2. Waterfall vs. TDD Process

3. Short-term advantages

4. Long-term advantages

5. Common critics and answers

Agenda

Test Driven Development TDD Formula

1. add a test

3. write enough code to pass the test

4. improve designthrough refactoring

2. get it to fail JUnitJUnit


User Story

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

Role:

Feature:

Business Value:


1. add a test...


2. get it to fail...

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


3. write code to pass the test...

... in the simplest possible way

JUnit


4. improve design

too simple in this case, later...

Test Driven Development TDD Formula

Start the loop again....

1. add a test





1. add a test...

think about the new API before it will be created

Test Driven Development 2. get the test to fail...

Generate now the new missing classes and methods


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

JUnit


by switching from a red bar to a green one, we tested our test itself

we fulfilled the test through last implementation

JUnitJUnit


4. improve design

JUnitany change

• evolve your design

• create only needed abstractions

• be always sure the code is still working


Start the loop again....

1. add a test





1. add a test...

motivate the next new feature by a test!



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



JUnit


3. write code to pass the test...

... in the simplest possible way

JUnit


4. improve design

always supporting your steps by the test, stay „green“

JUnit


Analysis

Design

Implementation

Test

CustomerProject Manager

ArchitectSenior Developer

Developer

DeveloperTester

A new feature or a small library

Classical waterfall process

How?

What?


Implementation

1. add a test

3. write code to pass the test

4. improve design2. get it to fail JUnitJUnit

Analysis

Design

Test=

The process resulting from TDD

What?

How?


Analysis Design

GAPFormal language lack

Behavior Driven Development (last evolvement TDD) is binding the user stories directly to the tests!

TDD vs Waterfall

ShoppingCart .... ...shouldHaveAListOfProductsInsideItself...shouldCalculateTheSubotalOfAllProductsInTheShoppingCart

Waterfall:

TDD:


Design

• predict the right design (M.Fowler, Is design dead?)

• think about everything upfront?

• sit down and think where to start, make random drafts

TDD vs Waterfall

Waterfall:

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


Implementation

TDD vs Waterfall

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

TDD:• 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


Test

• 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

Analysis Design Implementation

TDD vs Waterfall

Waterfall testing:

TDD: Your test is already done!


Analysis Test=

Is a test still a test ?

We should consider the test as specification of our requirements!

ShoppingCart .... ...shouldHaveAListOfProductsInsideItself...shouldCalculateTheSubotalOfAllProductsInTheShoppingCart

Behavior Driven Development (BDD) by Dan North

TDD vs Waterfall

Large adoption in the rails community with RSpec

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

Short-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

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

DAOImplStub

ImplementationValidationServiceImlpl

<<implements>><<implements>><<implements>>

Test Driven Development Pro and Contra, decide yourself....

• 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

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

• 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

Short termLong term

Time Invest into TDD and

Maintenance of Tests

VS


„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

test driven development by denis lutz

Education

test itselfwe

test driven development

driven development3

driven development4

driven development2

driven developmentmac

tdd process

evolvement tdd