Test-Driven Development

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

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

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

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

Extreme Programming Practices Overview source: www.xprogramming.com

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

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

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

Write code if and only if an automated unit test fails

Eliminate duplication and other “ smells”

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”

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”

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

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

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

Improves overall quality

Reduces number of bugs released

Reduces chances of bugs reoccuring

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.

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.

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

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.

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!

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!

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

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

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

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

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

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

Questions ?