An Introduction to

Test Driven Development

Michael DenomyNashua Scrum Club

January 13, 2011

www.mdenomy.wordpress.com

Goals

Basic understanding of TDD Benefits of TDD TDD in action TDD and Scrum Challenges to Implementing TDD Question and Answer

What Is Test Driven Development?

Iterative, test-first approach to development Functionality and behavior

The tests define the behavior we want API

Developed from client's perspective Design

Incremental, evolving with test definition Testing

Well tested software with high code coverage

History of TDD

Kent Beck recognized as originator of TDD Extreme Programming in mid 90's Initially used custom test fixtures

JUnit framework Developed by Beck and Erich Gamma in '97 Simplified writing and executing tests

JUnit ported to several languages .NET, C++, Python, PHP Referred to as xUnit frameworks

Benefits of TDDCase Studies

2008 study of 4 Projects using TDD1

Pre-release defects decreased 40-90% 15-35% increase in initial development time

Keith Braithwaite2 2008 study on cyclomatic complexity and automated tests

Projects with automated testing had lower complexity

Lower complexity → easier to refactor

Benefits of TDDOne Man's Experience

TDD for high-throughput DNA sequencer Complex, distributed system Software developed and tested before hardware Reduced integration times Low defects in product releases More trust among developers

Took some practice to get it right Hardly ever use a debugger anymore

I won't write production code without it

Red-Green-Refactor

TDD In ActionBanking 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

TDD and Team Collaboration

Banking examples were pretty simple, but we ended up with...

Executable specifications that describe the behavior of the system

Short, simple tests that are easy to understand Enables collaboration with

Product Owners to define and clarify behaviors Q/A to expose edge cases and failure modes Other developers to understand the behavior

and design

TDD and Communication

Continuous Integration XP practice that automates build and test Tests run on every check in

Results can show progress or identify areas for concern

Total tests, passing/failing tests Results must be visible to whole team

Use caution in interpreting metrics

TDD and Design

TDD encourages good design practices SOLID

Single Responsibility Principle

Open-Closed Principle

Liskov Substitution Principle

Interface Segregation Principle

Dependency Inversion Principle SOLID allows for modular, loosely coupled

systems

TDD and Design

YAGNI Don't put in code you don't need yet

DRY “Merciless refactoring to avoid duplication”

Separation of Concerns e.g. don't embed business logic in UI layer

Continually ask “How will I test this?”

These principles keep the code clean and easier to modify

TDD and DesignWhat 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

Challenges To TDD

Teams will struggle adopting TDD Requires strong design skills Writing “all that extra test code”

How much were you writing before?

Practice, practice, practice

“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.”

- James Shore

Introducing a New Team to TDD

Understand that teams new to TDD will struggle Start small

Pick a small project to gain experience Develop internal experts

Training options Coaching Pair programming Katas

Focus on good design practices

Summary

Enables better team communication Mechanism for team collaboration Tests become executable specifications

Encourages good design practices Small classes, loosely coupled

High test coverage Reduced defects, faster integration

Will have significant learning curve Practice, practice, practice

Books on Agile and TDD Kent Beck

Test-Driven Development By Example

James Shore

The Art of Agile Development

http://jamesshore.com/Agile-Book/

Roy Osherove

The Art of Unit Testing With Examples in .NET

Michael Feathers

Working Effectively With Legacy Code

Online Tutorials and Katas

James Shore - “Let's Play TDD” http://jamesshore.com/Blog/Lets-Play

Roy Osherove – String Calculator TDD Kata

http://www.osherove.com/tdd-kata-1/ List of TDD Exercises

http://sites.google.com/site/tddproblems/all-problems-1

Case Study References Realizing quality improvement through test

driven development: Nagappan, Maximilien, Bhat and Williamshttp://research.microsoft.com/en-us/groups/ese/nagappan_tdd.pdf

Keith Braithwaite – Quantifying the Effect of TDDhttp://www.keithbraithwaite.demon.co.uk/professional/presentations/2008/qcon/MeasureForMeasure.pdf

George Dinwiddie – Studies of TDDhttp://biblio.gdinwiddie.com/biblio/StudiesOfTestDrivenDevelopment

GoogleDoc Spreadheet on TDD Referenceshttps://spreadsheets.google.com/ccc?key=0AuC-Rc25Sw9VdEw0WE5wNmtIQ1d2eFA3UEFBUENfa0E

An Introduction to

Test Driven Development

Michael DenomyNashua Scrum Club

January 13, 2011

www.mdenomy.wordpress.com