test driven development
DESCRIPTION
Why should you use test driven development? Goals, benefits, principles, guidelines and tools.TRANSCRIPT
www.orbitone.com
Raas van Gaverestraat 83B-9000 GENT, Belgium E-mail [email protected] Website www.orbitone.com
Tel. +32 9 265 74 20Fax +32 9 265 74 10VAT BE 456.457.353Bank 442-7059001-50 (KBC)
13 May, 2008 Test driven development – “If it's worth building, it's worth testing”
Test driven development – “If it's worth building, it's worth testing” 2
Why should we use TDD?
Because we can't we get the design right from the beginning.
Why can't we get the design right from the beginning?
Because at the start of the project we have imperfect knowledge about the software we're developing.
13 May, 2008
Test driven development – “If it's worth building, it's worth testing” 3
What is TDD?
Software development technique
Related to the test-first programming concepts of Extreme Programming
TDD = TFD + Refactoring
13 May, 2008
Test driven development – “If it's worth building, it's worth testing” 4
Goals
To have a better code coverage test suite
To have specification before validation
To write clean code that works
But the real benefits are many more than the goals!
13 May, 2008
Test driven development – “If it's worth building, it's worth testing” 5
Principles and general guidelines
Write new business code only when an automated test has failed
When a test fails you have made progress because you now know that you
need to resolve the problem
TDD does not replace traditional testing, instead it defines a proven way to
ensure effective unit testing.
If it's worth building, it's worth testing.
If it's not worth testing, why are you wasting your time working on it?
13 May, 2008
Test driven development – “If it's worth building, it's worth testing” 6
Development cycle I - Steps
Create a test: basically just enough code to fail (testing the test)
Run the test to ensure that the test does in fact fail (testing the test)
Run minimal code necessary to pass the test
Refactor the code
Clean up
Remove duplication
Write a new test case ….
13 May, 2008
Test driven development – “If it's worth building, it's worth testing” 7
Development cycle II
13 May, 2008
Test driven development – “If it's worth building, it's worth testing” 8
Benefits
An interesting side effect of TDD: you achieve 100% coverage test
You have a short checklist – resolve one piece of functionality at
a time
Cleaner design than achieved by other methods
The design is easier to understand
The code becomes easier to work with as the project matures
The resulting code is designed for testability
13 May, 2008
Test driven development – “If it's worth building, it's worth testing” 9
Benefits – Safety net
Every single piece of functionality added will have a test
coverage. If anything ever changes, the developer will know
right away
Better assurance when integrating your code into source control
Refactoring becomes a lot easier, so the codebase can be kept
always healthy
13 May, 2008
Test driven development – “If it's worth building, it's worth testing” 10
Benefits – Usable design
Code that you develop through TDD is going to end up looking very
different from code you would have written otherwise
You don't start with a UML diagram, or a detailed class header file, or
anything like that
You start by using the feature you're about to implement
You're going to be your first user of your code, and you're going to think
about how to use it from the beginning
13 May, 2008
Test driven development – “If it's worth building, it's worth testing” 11
Benefits - Modularity
This is another side effect of having to use the code you're about to write
Isolated, modular tests => modular codebase
A highly modular codebase will compile much more quickly than one that has grown organically
13 May, 2008
Test driven development – “If it's worth building, it's worth testing” 12
Benefits – Documentation builds itself
The tests you write while doing TDD are the ideal low-level documentation for your code
For every feature, you have at least one example on how to use it correctly and how it's expected to be used.
And the best part is that it can't ever get out of date.
13 May, 2008
Test driven development – “If it's worth building, it's worth testing” 13
Misconception
The unit tests form 100% of your design specification
You only need to do unit test
TDD is sufficient for testing
TDD doesn't scale
Your test suite takes too long to run
Not all developers know how to test.
Everyone might not be taking a TDD approach.
13 May, 2008
Test driven development – “If it's worth building, it's worth testing” 14
Tools
Visual Studion Team System Test tools
NUnit
NCover
TestDriven.NET
13 May, 2008
Test driven development – “If it's worth building, it's worth testing” 15
Example using NUnit/VS integrated tool
Link to VS Solution
13 May, 2008
Test driven development – “If it's worth building, it's worth testing” 16
References
http://www.developer.com/design/article.php/3622546
http://homepage.mac.com/hey.you/lessons.html
http://www.gamesfromwithin.com/articles/0502/000073.html
http://msdn2.microsoft.com/en-us/magazine/cc163982.aspx
http://www.artima.com/intv/testdriven2.html
http://www.parlezuml.com/tutorials/agiledotnet/tdd_nunit.pdf
http://en.wikipedia.org/wiki/Test-driven_development
13 May, 2008
17 Test driven development – “If it's worth building, it's worth testing”
www.orbitone.com
13 May, 2008