Introduction to Test Driven Development

2,815 views

Published on

Introduction to Test Driven Development given at the Nashua Scrum Club 1/13/2011

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,815
On SlideShare
0
From Embeds
0
Number of Embeds
800
Actions
Shares
0
Downloads
50
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • I
  • T
  • More acronyms Can't tell you how many times I have worked on systems that have a bunch of stale code that the developer “thought we might need” Becomes technical debt, especially if it is not tested. Don't put in code you don't need, write tests for the code that you put in. Refactoring is the time that we look to improve ...ilities, like readabilty, maintainability, we do it as part of a tight red-green-refactor loop. Always happening Asking how will I test this forces us to think of good design practices
  • Introduction to Test Driven Development

    1. 1. An Introduction to Test Driven Development Michael Denomy Nashua Scrum Club January 13, 2011
    2. 2. Goals <ul><li>Basic understanding of TDD </li></ul><ul><li>Benefits of TDD </li></ul><ul><li>TDD in action </li></ul><ul><li>TDD and Scrum </li></ul><ul><li>Challenges to Implementing TDD </li></ul><ul><li>Question and Answer </li></ul>
    3. 3. What Is Test Driven Development? <ul><li>Iterative, test-first approach to development </li></ul><ul><li>Functionality and behavior </li></ul><ul><ul><li>The tests define the behavior we want </li></ul></ul><ul><li>API </li></ul><ul><ul><li>Developed from client's perspective </li></ul></ul><ul><li>Design </li></ul><ul><ul><li>Incremental, evolving with test definition </li></ul></ul><ul><li>Testing </li></ul><ul><ul><li>Well tested software with high code coverage </li></ul></ul>
    4. 4. History of TDD <ul><li>Kent Beck recognized as originator of TDD </li></ul><ul><ul><li>Extreme Programming in mid 90's </li></ul></ul><ul><ul><li>Initially used custom test fixtures </li></ul></ul><ul><li>JUnit framework </li></ul><ul><ul><li>Developed by Beck and Erich Gamma in '97 </li></ul></ul><ul><ul><li>Simplified writing and executing tests </li></ul></ul><ul><li>JUnit ported to several languages </li></ul><ul><ul><li>.NET, C++, Python, PHP </li></ul></ul><ul><ul><li>Referred to as xUnit frameworks </li></ul></ul>
    5. 5. Benefits of TDD Case Studies <ul><li>2008 study of 4 Projects using TDD 1 </li></ul><ul><ul><li>Pre-release defects decreased 40-90% </li></ul></ul><ul><ul><li>15-35% increase in initial development time </li></ul></ul><ul><li>Keith Braithwaite 2 2008 study on cyclomatic complexity and automated tests </li></ul><ul><ul><li>Projects with automated testing had lower complexity </li></ul></ul><ul><ul><li>Lower complexity -> easier to refactor </li></ul></ul>
    6. 6. Benefits of TDD One Man's Experience <ul><li>TDD for high-throughput DNA sequencer </li></ul><ul><ul><li>Complex, distributed system </li></ul></ul><ul><ul><li>Software developed and tested before hardware </li></ul></ul><ul><ul><li>Reduced integration times </li></ul></ul><ul><ul><li>Low defects in product releases </li></ul></ul><ul><ul><li>More trust among developers </li></ul></ul><ul><li>Took some practice to get it right </li></ul><ul><li>Hardly ever use a debugger anymore </li></ul><ul><li>I won't write production code without it </li></ul>
    7. 7. Red-Green-Refactor
    8. 8. TDD In Action Banking User Stories Open Account As a customer, I want to open a bank account with an initial deposit >= 0 dollars. After opening the account, the account balance should be the amount of the initial deposit. Deposit Funds As a customer, I want make a deposit into a bank account. After the deposit, the account balance should be the previous balance plus the amount of the deposit. The deposit amount must be >= 0 dollars Let's write some code
    9. 10. TDD and Team Collaboration <ul><li>Banking examples were pretty simple, but we ended up with... </li></ul><ul><li>Executable specifications that describe the behavior of the system </li></ul><ul><li>Short, simple tests that are easy to understand </li></ul><ul><li>Enables collaboration with </li></ul><ul><ul><li>Product Owners to define and clarify behaviors </li></ul></ul><ul><ul><li>Q/A to expose edge cases and failure modes </li></ul></ul><ul><ul><li>Other developers to understand the behavior and design </li></ul></ul>
    10. 11. TDD and Communication <ul><li>Continuous Integration </li></ul><ul><ul><li>XP practice that automates build and test </li></ul></ul><ul><ul><li>Tests run on every check in </li></ul></ul><ul><li>Results can show progress or identify areas for concern </li></ul><ul><ul><li>Total tests, passing/failing tests </li></ul></ul><ul><ul><li>Results must be visible to whole team </li></ul></ul><ul><li>Use caution in interpreting metrics </li></ul>
    11. 12. TDD and Design <ul><li>TDD encourages good design practices </li></ul><ul><li>SOLID </li></ul><ul><ul><li>S ingle Responsibility Principle </li></ul></ul><ul><ul><li>O pen-Closed Principle </li></ul></ul><ul><ul><li>L iskov Substitution Principle </li></ul></ul><ul><ul><li>I nterface Segregation Principle </li></ul></ul><ul><ul><li>D ependency Inversion Principle </li></ul></ul><ul><li>SOLID allows for modular, loosely coupled systems </li></ul>
    12. 13. TDD and Design <ul><li>YAGNI </li></ul><ul><ul><li>Don't put in code you don't need yet </li></ul></ul><ul><li>DRY </li></ul><ul><ul><li>“ Merciless refactoring to avoid duplication” </li></ul></ul><ul><li>Separation of Concerns </li></ul><ul><ul><li>e.g. don't embed business logic in UI layer </li></ul></ul><ul><li>Continually ask “How will I test this?” </li></ul><ul><li>These principles keep the code clean and easier to modify </li></ul>
    13. 14. TDD and Design What Others Have To Say If TDD has never led you to an unexpected design, you've got more to learn @JoshuaKerievsky The act of writing a unit test is more an act of design than of verification. It is also more an act of documentation than of verification Bob Martin, “Uncle Bob” ...you're always thinking about design. Either you're deciding which test you're going to write next, which is an interface design process, or you're deciding how to refactor, which is a code design process. James Shore
    14. 15. Challenges To TDD <ul><li>Teams will struggle adopting TDD </li></ul><ul><ul><li>Requires strong design skills </li></ul></ul><ul><ul><li>Writing “all that extra test code” </li></ul></ul><ul><ul><ul><li>How much were you writing before? </li></ul></ul></ul><ul><li>Practice, practice, practice </li></ul><ul><ul><li>“ The basic steps of TDD are easy to learn, but the mindset takes a while to sink in. Until it does, TDD will likely seem clumsy, slow, and awkward. Give yourself two or three months of full-time TDD use to adjust.” </li></ul></ul><ul><ul><li>- James Shore </li></ul></ul>
    15. 16. Introducing a New Team to TDD <ul><li>Understand that teams new to TDD will struggle </li></ul><ul><li>Start small </li></ul><ul><ul><li>Pick a small project to gain experience </li></ul></ul><ul><ul><li>Develop internal experts </li></ul></ul><ul><li>Training options </li></ul><ul><ul><li>Coaching </li></ul></ul><ul><ul><li>Pair programming </li></ul></ul><ul><ul><li>Katas </li></ul></ul><ul><li>Focus on good design practices </li></ul>
    16. 17. Summary <ul><li>Enables better team communication </li></ul><ul><ul><li>Mechanism for team collaboration </li></ul></ul><ul><ul><li>Tests become executable specifications </li></ul></ul><ul><li>Encourages good design practices </li></ul><ul><ul><li>Small classes, loosely coupled </li></ul></ul><ul><li>High test coverage </li></ul><ul><ul><li>Reduced defects, faster integration </li></ul></ul><ul><li>Will have significant learning curve </li></ul><ul><ul><li>Practice, practice, practice </li></ul></ul>
    17. 18. Books on Agile and TDD <ul><li>Kent Beck </li></ul><ul><ul><li>Test-Driven Development By Example </li></ul></ul><ul><li>James Shore </li></ul><ul><ul><li>The Art of Agile Development </li></ul></ul><ul><ul><li>http://jamesshore.com/Agile-Book/ </li></ul></ul><ul><li>Roy Osherove </li></ul><ul><ul><li>The Art of Unit Testing With Examples in .NET </li></ul></ul><ul><li>Michael Feathers </li></ul><ul><ul><li>Working Effectively With Legacy Code </li></ul></ul>
    18. 19. Online Tutorials and Katas <ul><li>James Shore - “Let's Play TDD” http://jamesshore.com/Blog/Lets-Play </li></ul><ul><li>Roy Osherove – String Calculator TDD Kata </li></ul><ul><ul><li>http://www.osherove.com/tdd-kata-1/ </li></ul></ul><ul><li>List of TDD Exercises </li></ul><ul><ul><li>http://sites.google.com/site/tddproblems/all-problems-1 </li></ul></ul>
    19. 20. Case Study References <ul><li>Realizing quality improvement through test driven development: Nagappan, Maximilien, Bhat and Williams </li></ul><ul><ul><li>http://research.microsoft.com/en-us/groups/ese/nagappan_tdd.pdf </li></ul></ul><ul><li>Keith Braithwaite – Quantifying the Effect of TDD </li></ul><ul><ul><li>http://www.keithbraithwaite.demon.co.uk/professional/presentations/2008/qcon/MeasureForMeasure.pdf </li></ul></ul><ul><li>George Dinwiddie – Studies of TDD </li></ul><ul><ul><li>http://biblio.gdinwiddie.com/biblio/StudiesOfTestDrivenDevelopment </li></ul></ul><ul><li>GoogleDoc Spreadheet on TDD References </li></ul><ul><ul><li>https://spreadsheets.google.com/ccc?key=0AuC-Rc25Sw9VdEw0WE5wNmtIQ1d2eFA3UEFBUENfa0E </li></ul></ul>
    20. 21. An Introduction to Test Driven Development Michael Denomy Nashua Scrum Club January 13, 2011

    ×