Test-driven development (TDD) is a software development technique where unit tests are written before code to define desired functionality. Writing tests first helps produce code with better design, lower maintenance costs, and fewer bugs. Key principles of TDD include writing code only to pass failing tests and eliminating duplication. Benefits include better test coverage, easier refactoring, and preventing regressions. TDD helps developers act as users to define behavior through interactions between system components.

1. Test-Driven Development

2. Why Test-Driven Development (TDD)? Agile implies adapting to change quickly… In code, this translates to “easy to maintain & refactor” and implies… Clean design No duplication Low/loose coupling Eliminating “code smells” Thorough test coverage TDD is a technique that helps getting there

3. What is TDD? Originates from test-first programming concepts of Extreme Programming (XP) Is a software design method more than a testing method Developers create automated unit tests that define code requirements before writing the code itself

4. Extreme Programming Practices Overview source: www.xprogramming.com

5. The TDD cycle Add a test Run all tests and see if the new one fails Write code Run all tests and see the new test succeed Refactor the code Test Code Refactor source: Test-Driven Development by Example, by Kent Beck

6. TDD Key Principles Write code if and only if an automated unit test fails Eliminate duplication and other “ smells”

7. Benefits If done well, TDD can bring tons of benefits: Better test coverage A safety net for refactoring Helps prevent regression Measurable Better design Developer acts as user of his own code Looser coupling Easier to test Constant elimination of “code smells”

8. Benefits (continued) Functionality required only “ You Ain’t Gonna Need It” (YAGNI) principle Lower maintenance cost Helps managing fear in face of complexity Brings confidence in the code base Decreases pressure Documents code Lots of example usage of the code

9. Benefits (continued) Improves overall quality Reduces number of bugs released Reduces chances of bugs reoccuring

10. TDD Adoption Stages The developer starts writing unit tests around their code using a test framework like JUnit or TestNG. As the body of tests increases the developer begins to enjoy a strongly increased sense of confidence in their work. 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.

11. TDD Adoption Stages (continued) 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. A point of revelation occurs when the developer realizes that writing tests in this way helps them to "discover" the API to their code. TDD has now become a design process. 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. Behavior is about the interactions between components of the system and so the use of mocking is a fundamental to advanced TDD. source: www.behaviour-driven.org

12. Pitfall stopping midway Too many integration tests vs unit tests Tests more complex Tests become constraint on change Tests take much time to run Tests code tightly coupled to implementation A common failure mode for code bases on Agile projects A solution: Use Mocks!

13. Adopting a test strategy Unit tests Integration tests Functional tests Acceptance tests + - $$

14. Another Categorization Unit tests Integration tests + - $$ Unit tests Integration tests End-to-end tests Customer tests Developer tests

15. Making TDD stick Classroom training Use measurement tools Pair programming Support from management Community Coding dojos Reading workshops Patience… it will take more time than you expect! Pizza source: www.infoq.com, Making TDD stick, Problems and Solutions for Adopters, by Mark Levison

16. References Test-Driven Development by Example , Kent Beck – Addison-Wesley, 2002 http://www.xprogramming.com http://www.behaviour-driven.org Making TDD Stick, Problems and Solutions for Adopters , Mark Levison, http://www.infoq.com, January 2009

17. Questions ?