 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

The pain is here! This is too late…
100% 10
9
80% 8
% defects created
7
Thousand $s
60% 6
5
40% 4
3
20% 2
1
0% 0
Requirements Coding Integration Testing Support
% of Defects Introduced Cost to Fix a Defect

 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  Resharper
 MbUnit  TDD.NET
 JUnit
 RefactorPro!
 JSSpec
 xUnit.net  Visual Studio
 Moq
 Rhino Mocks
 Mosquito

New
requireme
nt
Write
Run tests
new test
Refactor Run tests
Write
Run tests new
code

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