 It’s not about testing, but about design
  and development(specification).
 Short development iteration.
 Is a design ...
   Write Test Code
       Code that fulfills requirements
   Write Functional Code
       Working code that fulfills r...
 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%                                                     ...
   Make you think about requirement
    behaviour.
   Provide documentation.
   Improve quality.
   Reduce speculative...
 I don’t have time to unit test.
 The client pays me to develop code, not
  write unit test.
 I am supporting a legacy ...
 It forces you to really understand the
  code.
 It forces you to really understand the
  tests
 It forces you to creat...
 Enabling TDD
 TDD Cycle
 Choosing the First Test?
 Green Bar Patterns
 State-based vs. Interaction-based Unit
  Test...
   NUnit          Resharper
   MbUnit         TDD.NET
   JUnit
                   RefactorPro!
   JSSpec
   xUnit....
New
                        requireme
                            nt


                                             Write
...
 The simplest.
 The essence.
    •If you need to write code that is
    untested, choose a simpler test.
    •If the ess...
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 a...
   Fake It(TilYou Make It)
       Start with hardcoded results and wait until later
        tests to force them to becom...
TDD sharevison team
TDD sharevison team
TDD sharevison team
TDD sharevison team
TDD sharevison team
TDD sharevison team
Upcoming SlideShare
Loading in...5
×

TDD sharevison team

435

Published on

This TDD slide, has been presented during Barcamp PP2

Published in: Sports
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
435
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

TDD sharevison team

  1. 1.  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.
  2. 2.  Write Test Code  Code that fulfills requirements  Write Functional Code  Working code that fulfills requirements  Refactor  Clean working code that fulfills requirements
  3. 3.  Unneccessary Code, features or functionality.  Unchangeable code.  Unscallable code.
  4. 4.  Carefully plan  Make the change  Start the application and check the change  Poking aroud
  5. 5.  Write test  Make the change  Run all tests
  6. 6. 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
  7. 7.  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
  8. 8.  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.
  9. 9.  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.
  10. 10.  Enabling TDD  TDD Cycle  Choosing the First Test?  Green Bar Patterns  State-based vs. Interaction-based Unit Testing
  11. 11.  NUnit  Resharper  MbUnit  TDD.NET  JUnit  RefactorPro!  JSSpec  xUnit.net  Visual Studio  Moq  Rhino Mocks  Mosquito
  12. 12. New requireme nt Write Run tests new test Refactor Run tests Write Run tests new code
  13. 13.  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.
  14. 14. Do not write the code in your head before you write the test
  15. 15.  Small and focused  Intention revealing  Repeatable  Independent  Have no side-effects
  16. 16. •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
  17. 17.  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.
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×