A quick paced introduction to "Test Driven Development" (TDD) in an agile environment. The TDD philosophy states that you should develop your tests and then write code to make your tests pass and satisfy user requirements.

1. Test Driven Development
In An Agile Environment
Presented by Mr. Viraf Karai
on Mon. Jan 19, 2009

2. Topics covered
Agile manifesto Myths about TDD
 
Evolutionary dvlp & TDD benefits
 
design Ideal qualities of unit

TDD philosophy tests

TDD steps Resources
 
TDD states

Legacy development

2

3. The Agile Manifesto
Composed by heavy hitters in the software industry

in Snowbird, UT in February 2001
Included folks backing methodologies such as

Scrum, XP, Crystal, Feature driven developemt, etc.
Big names such as Martin Fowler, Robert C Martin

(Uncle Bob), Alistair Cockburn, Ken Schwaber,
Dave Thomas, etc.
3

4. The Agile Manifesto – principles
Primary metric of progress is
Continuous delivery 

working software
Welcome changing reqs

All participants should

Deliver working software

maintain a constant pace
frequently
Continuous attention to tech

Involve biz and developers

excellence & good design
throughout the project
Simplicity is essential

Build projects around

Self organizing teams
motivated folks 
Periodic retrospectives
Communication should be 

face­to­face
4

5. A couple of quotes
The act of writing a unit test is more an act of design
than verification (Robert C Martin aka Uncle Bob)
Walking on water and developing software from a
specification are both easy if both are frozen
(Edward V. Berard)
5

6. Evolutionary dvlp and design
Evolutionary development is an iterative and incremental approach
to software development.
Instead of creating a comprehensive artifact, such as a requirements

specification, that you review and accept before creating a
comprehensive design model (and so on) you instead evolve the
critical development artifacts over time in an iterative manner.
Instead of building and then delivering your system in a single “big

bang” release you instead deliver it incrementally over time. Yes, you
will likely still need to do some initial requirements and architecture
envisioning, but this is at a high level ­­ I can't say this enough, you
don't need to do big modeling up­front (BMUF)
– Scott Ambler
6

7. Evolutionary design steps
7

8. Test Driven Dvlp (TDD) Philosophy
The basic tenets are developing and implementing

unit tests before writing a line of code
Unit tests will and must fail up front

Code is developed after the test is developed.

A unique idea that is still foreign to many

developers
8

9. TDD steps
9

10. TDD steps
Quickly add a test ­ just enough code to fail test

Run test­suite to ensure test fails (may choose to run

a subset of suite)
Update your functional code to ensure new test

passes
Re­run test suite and keep updating functional code

until test passes
Refactor and move on

10

11. TDD states
11

12. TDD and agile
TDD implies agile.

Strong emphasis on testing

Tests should span entire breadth of codebase

Once all software is ready for delivery, all tests

should pass
A unique way to address modern challenges in

software development
12

13. Legacy software dvlp and testing
Mostly implies a waterfall/big­bang process

Very little emphasis on unit testing by developers

Tests are almost developed as an afterthought

Tests are mostly manual

Huge emphasis on QA team

Delivering quality software on time and within

budget is almost accidental
13

14. Myths about TDD
Myth: TDD is ok for small projects involving a

handful of folks but won't scale to large projects
involving scores or hundreds of people.
Answer: Not true.

Kent Beck worked on a pure TDD project developed in

Smalltalk.
4 years and 40 man years of effort resulting in 250K lines

of func code and 250K lines of test code
4,000 tests run in under 20 mins

Full suite runs several times a day

14

15. TDD benefits
Shortens the programming feedback

Provides detailed (executable) specifications

Promotes development of high­quality code

Provides concrete evidence that your code works

Requires developers to prove it with code

Provides finely­grained, concrete feedback (in mins)

Ensures that your design is clean by focusing on creation of

operations that are callable and testable
Supports evolutionary development

15

16. Six ideal qualities of unit tests
Decisive – has all info to determine success/failure

Valid – produces a result that matches the intention of the work

artifact under test
Complete ­ contains all the information it needs to run correctly with

a given test harness and work artifact under test
Repeatable ­ always gives the same results if the test harness and the

artifact under test are the same i.e. Is deterministic
Isolated ­ is not affected by other tests run before it nor does a test

affect the results of tests run after it
Automated ­ requires only a start signal in order to run to completion

in a finite amount of time
16

17. Why TDD
If it's worth building, it's worth testing.
If it's not worth testing, why are you
wasting your time working on it?
­ Scott Ambler
17

18. Resources
Test Driven Development By Example – Kent Beck

Test Driven: TDD And Acceptance TDD For Java

Developers ­ Lasse Koskela
http://www.testdriven.com

http://www.agiledata.org

Junit 4 in 10 minutes

http://www.instrumentalservices.com/media/articles/java
18

19. Questions
19