It’s not about testing, but about design and development(specification).

Short development iteration.

Is a design process.

Based on requirement and pre-written test.

Tests are your first user.

The goal is to produce working clean code, that fullfill the requirement.

If TDD hurt you, that mean you do it wrong.

Write Test Code Code that fulfills requirements

Write Functional Code Working code that fulfills requirements

Refactor Clean working code that fulfills requirements

Unneccessary Code, features or

functionality.

Unchangeable code.

Unscallable code.

Carefully plan

Make the change

Start the application and check the

change

Poking aroud

Write test

Make the change

Run all tests

0

1

2

3

4

5

6

7

8

9

10

0%

20%

40%

60%

80%

100%

Requirements Coding Integration Testing Support

Tho

usa

nd

$s

% d

efe

cts

cre

ate

d

% of Defects Introduced Cost to Fix a Defect

The pain is here! This is too late…

Make you think about requirement behaviour.

Provide documentation.

Improve quality.

Reduce speculative code.

Less time debuggin.• Confidence in change, Fearlessly change your

code

Discover usablity issue early

Regression testing = Stable software = Quality software

I don’t have time to unit test.

The client pays me to develop code, not

write unit test.

I am supporting a legacy application

without unit tests.

QA and User Acceptance Testing is far

more effective in finding bugs.

I don’t know how to unit test, or I don’t

know how to write good unit tests.

It forces you to really understand the

code.

It forces you to really understand the

tests

It forces you to create code that is truly

reusable and modular and testable

These forces drive you to keep your

code and your tests simple and easy to

understand.

Enabling TDD

TDD Cycle

Choosing the First Test?

Green Bar Patterns

State-based vs. Interaction-based Unit

Testing

NUnit

MbUnit

JUnit

JSSpec

xUnit.net

Moq

Rhino Mocks

Mosquito

Resharper

TDD.NET

RefactorPro!

Visual Studio

New requireme

nt

Writenew test

Run tests

Writenew

codeRun tests

Refactor

Run tests

The simplest.

The essence.

•If you need to write code that is

untested, choose a simpler test.

•If the essence approach takes to much

time to implement, choose a simpler

test.

Do not

write the code in your head

before you write the test

Small and focused

Intention revealing

Repeatable

Independent

Have no side-effects

•Domain-specific

•Suitable for customer comprehension

•Understandable in absence of code

•Think about behavior

•Think about the context of the

behavior

•Focus on the words, not the

implementation

Fake It(TilYou Make It) Start with hardcoded results and wait until later

tests to force them to become real.

Triangulate To Abstraction Make the code abstract only when you have

two or more examples.

Obvious Implementation aka Don't Be Stupid

If you really, really, honestly know the right way

to implement it, then write it that way.