Test Driven Development (TDD) involves writing tests before code to drive the development process. It emphasizes: 1. Starting with writing an acceptance test for the thinnest slice of functionality, known as a "walking skeleton". 2. Writing unit tests by following the "write tests backwards" approach of specifying the test name, call to code, and expectations before writing code to pass the test. 3. Using mock objects to guide interface design by specifying the required services of an object rather than its provided features, promoting narrow, role-based interfaces between objects.

1. Test Driven Development

2. Why Test Driven Development ?
Pair
Programming
Unit Tests
Acceptance
Tests
Daily
meetings
Iterations
Releases
Agile insists
on constant
feedback in
all levels
Empirical
Feedback

3. Acceptance test driven development
Write a failing
acceptance test
Write a
failing
unit test
Make the
test pass
Refactor
Regression
Test
suite
Measure of
demonstrable
progress

4. •Start with Testing a walking skeleton
•A “walking skeleton” is an implementation of the thinnest possible slice of
real functionality that we can automatically build, deploy, and test end-to-end.
Eg., for a database-backed web application, a skeleton would show a flat web page with
fields from the database
•The “end” in “end-to-end” refers to the process, as well as the system
How to startTDD?

5. How do we write a test ?
Write Tests Backwards
•Write the test name - helps us decide what we want to achieve;
•Write the call to the target code - is the entry point for the feature;
•Write the expectations and assertions - know what effects the feature
should have;
•Write the setup and teardown to define the context for the test
This sequence reflects how we tend to think through a new unit test. Then we run it and
watch it fail.

6. Object Oriented Programming
A Train Wreck
(This is bad because this
one line depends on the interfaces
and implied structure of three
different objects.)
dog.getBody().getTail().wag();
Solution:
"Tell, Don't Ask”
dog.expressHappiness();
An object should
only talk to its
neighbors

7. Role of Mockobjects
TDD with Mock Objects guides
interface design by the services
that an object requires, not just
those it provides.
System of narrow interfaces each
of which defines a role in an
interaction between objects,
rather than wide interfaces that
describe all the features
provided by a class.
LEAN

8. Format of TDD using Mockobjects
Create instances of Mock
Objects
Set state in the Mock Objects
Set expectations in the Mock
Objects
Invoke domain code with Mock
Objects as parameters
Verify consistency in the Mock
Objects

9. TDD for distributed teams
"Collective Code Ownership" is critical to distributed agile teams
Continuous Integration should accommodate infrastructure for
TDD
You can’t go home with anything that doesn’t build !!