TDD sharevison team

544 views

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
544
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
10
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.

×