1. Test Driven Development
Want to go for a drive?
Copyright © by Curt Hill

2. Copyright © 2015-2017 by Curt Hill
Introduction
Attributed to Kent Beck
Claims he rediscovered it
Popularized in a 2002 book
This method is based on the notion of unit tests being primary
We write unit tests first
Then generate just enough code to pass the tests
Copyright © by Curt Hill

3. Copyright © 2015-2017 by Curt Hill
Quote
If it’s worth building, it’s worth testing If it’s not worth testing, why are you wasting your time working on it?
Copyright © by Curt Hill

4. Copyright © 2015-2017 by Curt Hill
The Cycle
TDD uses the following set of steps
Repeat
Add a test
Run all tests
Write or update the code, possibly with a refactor step
Run tests
Copyright © by Curt Hill

5. Copyright © 2015-2017 by Curt Hill
Flow Graph
Copyright © by Curt Hill

6. Copyright © 2015-2017 by Curt Hill
Add a test
We first create a unit test for a new feature
The test defines the feature or enhancement that we need
Requires understanding of the requirements
Based on use-cases or user stories
This precedes the creation of any code
Copyright © by Curt Hill

7. Copyright © 2015-2017 by Curt Hill
Run Tests
Several things need to be confirmed here
Initial runs we confirm that the unit test system works
In all runs we find out far we missed the mark
If a new test does not create any new errors
Either poor test or we have discovered capabilities that already existed and no new code is needed
Usually we see the lack of capability
Copyright © by Curt Hill

8. Copyright © 2015-2017 by Curt Hill
Write/Change Code
The first time a test fails we usually create a new class/method/function
We write the minimum amount of code to pass the test
No guessing as to what will be needed in the future
We loop back through tests until we pass
This is often the stage where refactoring also occurs
Copyright © by Curt Hill

9. Copyright © 2015-2017 by Curt Hill
Run Tests Again
When all the tests have been passed we ask the question
Have we implemented all that we need?
Has every user story been implemented?
If so the program is done otherwise we create new tests for new use cases/user stories
Copyright © by Curt Hill

10. Copyright © 2015-2017 by Curt Hill
Two Levels of Tests
Acceptance tests cover the entire system
Unit tests cover a single class or function
The difference is largely one of scope
The upper most class is usually the program
It’s unit test is an acceptance test
Copyright © by Curt Hill

11. Copyright © 2015-2017 by Curt Hill
Random Thoughts
The unit tests are automated in some fashion
Passing the unit test that we are shooting for and causing another one to fail is unacceptable
One study showed that developers using TDD on new projects seldom needed to use a debugger
Higher level unit tests tended to generate false errors
Copyright © by Curt Hill

12. Copyright © 2015-2017 by Curt Hill
TDD and XP
Test Driven Development is at the heart of eXtreme Programming
TDD is a subset of XP
XP prescribes many other practices that are not TDD
TDD may also be used in many other agile processes, such as Scrum
Copyright © by Curt Hill

13. Traditional testing and TDD
Traditionally developers use tests to find defects in the code
TDD does this as well
Traditional testing is applied after the code is written
TDD is before
TDD also uses the tests as a documentation of the specfications
Some refer to the TDD as a specification technique with the side effect of better testing of the code
Copyright © by Curt Hill

14. Copyright © 2015-2017 by Curt Hill
Finally
The key to TDD is to convert use cases or user stories directly into tests
Then generate the code to pass the tests
The tests are both specifications and tests
An executable specification of sorts
Finally for now
Copyright © by Curt Hill