Test Driven Development In An Agile Environment Presented by Mr. Viraf Karai on Mon. Jan 19, 2009
Topics covered
Agile manifesto Evolutionary dvlp & design
TDD philosophy
TDD steps
TDD states
Legacy development
Myths about TDD
TDD benefits
Ideal qualities of unit tests Resources
2
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
The Agile Manifesto – principles
Continuous delivery
Welcome changing reqs
Deliver working software frequently Involve biz and developers throughout the project Build projects around motivated folks Communication should be facetoface
Primary metric of progress is working software All participants should maintain a constant pace Continuous attention to tech excellence & good design
Simplicity is essential
Self organizing teams
Periodic retrospectives
4
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
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 upfront (BMUF)
– Scott Ambler
6
Evolutionary design steps
7
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
TDD steps
9
TDD steps
Quickly add a test just enough code to fail test Run testsuite to ensure test fails (may choose to run a subset of suite) Update your functional code to ensure new test passes Rerun test suite and keep updating functional code until test passes Refactor and move on
10
TDD states
11
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
Legacy software dvlp and testing
Mostly implies a waterfall/bigbang 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
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
TDD benefits
Shortens the programming feedback
Provides detailed (executable) specifications
Promotes development of highquality code
Provides concrete evidence that your code works
Requires developers to prove it with code
Provides finelygrained, 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
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
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
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
Questions
19