Test Driven Development - Overview and Adoption


Published on

- What is TDD
- TDD adoption stages
- Adopting a test strategy
- Making TDD stick

Published in: Technology, Education
1 Comment
  • Não consegui realizar o download, poderia me disponibilizar por e-mail?

    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Test Driven Development - Overview and Adoption

  1. 1. Test-Driven Development
  2. 2. Why Test-Driven Development (TDD)? <ul><li>Agile implies adapting to change quickly… </li></ul><ul><li>In code, this translates to “easy to maintain & refactor” and implies… </li></ul><ul><ul><li>Clean design </li></ul></ul><ul><ul><li>No duplication </li></ul></ul><ul><ul><li>Low/loose coupling </li></ul></ul><ul><ul><li>Eliminating “code smells” </li></ul></ul><ul><ul><li>Thorough test coverage </li></ul></ul><ul><li>TDD is a technique that helps getting there </li></ul>
  3. 3. What is TDD? <ul><li>Originates from test-first programming concepts of Extreme Programming (XP) </li></ul><ul><li>Is a software design method more than a testing method </li></ul><ul><li>Developers create automated unit tests that define code requirements before writing the code itself </li></ul>
  4. 4. Extreme Programming Practices Overview source: www.xprogramming.com
  5. 5. The TDD cycle <ul><li>Add a test </li></ul><ul><li>Run all tests and see if the new one fails </li></ul><ul><li>Write code </li></ul><ul><li>Run all tests and see the new test succeed </li></ul><ul><li>Refactor the code </li></ul>Test Code Refactor source: Test-Driven Development by Example, by Kent Beck
  6. 6. TDD Key Principles <ul><li>Write code if and only if an automated unit test fails </li></ul><ul><li>Eliminate duplication and other “ smells” </li></ul>
  7. 7. Benefits <ul><li>If done well, TDD can bring tons of benefits: </li></ul><ul><li>Better test coverage </li></ul><ul><ul><li>A safety net for refactoring </li></ul></ul><ul><ul><li>Helps prevent regression </li></ul></ul><ul><ul><li>Measurable </li></ul></ul><ul><li>Better design </li></ul><ul><ul><li>Developer acts as user of his own code </li></ul></ul><ul><ul><li>Looser coupling </li></ul></ul><ul><ul><li>Easier to test </li></ul></ul><ul><ul><li>Constant elimination of “code smells” </li></ul></ul>
  8. 8. Benefits (continued) <ul><li>Functionality required only </li></ul><ul><ul><li>“ You Ain’t Gonna Need It” (YAGNI) principle </li></ul></ul><ul><ul><li>Lower maintenance cost </li></ul></ul><ul><li>Helps managing fear in face of complexity </li></ul><ul><ul><li>Brings confidence in the code base </li></ul></ul><ul><ul><li>Decreases pressure </li></ul></ul><ul><li>Documents code </li></ul><ul><ul><li>Lots of example usage of the code </li></ul></ul>
  9. 9. Benefits (continued) <ul><li>Improves overall quality </li></ul><ul><ul><li>Reduces number of bugs released </li></ul></ul><ul><ul><li>Reduces chances of bugs reoccuring </li></ul></ul>
  10. 10. TDD Adoption Stages <ul><li>The developer starts writing unit tests around their code using a test framework like JUnit or TestNG. </li></ul><ul><li>As the body of tests increases the developer begins to enjoy a strongly increased sense of confidence in their work. </li></ul><ul><li>At some point the developer has the insight (or are shown) that writing the tests before writing the code, helps them focus on only writing the code that they need. </li></ul>
  11. 11. TDD Adoption Stages (continued) <ul><li>The developer also notices that when they return to some code that they haven't seen for a while, the tests serve to document how the code works. </li></ul><ul><li>A point of revelation occurs when the developer realizes that writing tests in this way helps them to &quot;discover&quot; the API to their code. TDD has now become a design process. </li></ul><ul><li>Expertise in TDD begins to be drawn at the point where the developer realizes that TDD is not about testing, it is about defining behavior. </li></ul><ul><li>Behavior is about the interactions between components of the system and so the use of mocking is a fundamental to advanced TDD. </li></ul>source: www.behaviour-driven.org
  12. 12. Pitfall stopping midway <ul><li>Too many integration tests vs unit tests </li></ul><ul><li>Tests more complex </li></ul><ul><li>Tests become constraint on change </li></ul><ul><li>Tests take much time to run </li></ul><ul><li>Tests code tightly coupled to implementation </li></ul><ul><li>A common failure mode for code bases on Agile projects </li></ul><ul><li>A solution: Use Mocks! </li></ul>
  13. 13. Adopting a test strategy Unit tests Integration tests Functional tests Acceptance tests + - $$
  14. 14. Another Categorization Unit tests Integration tests + - $$ Unit tests Integration tests End-to-end tests Customer tests Developer tests
  15. 15. Making TDD stick <ul><li>Classroom training </li></ul><ul><li>Use measurement tools </li></ul><ul><li>Pair programming </li></ul><ul><li>Support from management </li></ul><ul><li>Community </li></ul><ul><li>Coding dojos </li></ul><ul><li>Reading workshops </li></ul><ul><li>Patience… it will take more time than you expect! </li></ul><ul><li>Pizza </li></ul>source: www.infoq.com, Making TDD stick, Problems and Solutions for Adopters, by Mark Levison
  16. 16. References <ul><li>Test-Driven Development by Example , </li></ul><ul><li>Kent Beck – Addison-Wesley, 2002 </li></ul><ul><li>http://www.xprogramming.com </li></ul><ul><li>http://www.behaviour-driven.org </li></ul><ul><li>Making TDD Stick, Problems and Solutions for Adopters , Mark Levison, http://www.infoq.com, January 2009 </li></ul>
  17. 17. Questions ?