What are the goals of TDD? What are the problem of TDD?

1. TDD
Test Driven Development

2. Software Quality
• A definition in Steve McConnell's Code
Complete divides software into two pieces:
internal and external quality
characteristics.
• External quality characteristics are those
parts of a product that face its users,
where internal quality characteristics are
those that do not.

3. ISO/IEC 9126-1:2001(E)
Internal and External Features
•
•
•
•
•
•
Functionality
Reliability
Usability
Efficiency
Maintainability
Portability

4. ISO/IEC 9126-1:2001(E)
Quality-in-use features
•
•
•
•
Effectiveness
Productivity
Safety
Customer Satisfaction
• It is the user’s view of the quality of the
software product when it is used in a specific
environment and a specific Context-Of-Use.

5. TDD in summary
A. First we write a test.
B. Then we write code to make the test
pass.
C. Then we find the best possible design for
what we have - refactoring (Relying on the
existing tests to keep us from breaking things
while we are at it)

6. TDD goals
•
TDD is a technique for improving the
software’s internal quality
Well-written code
• Good design
• A balanced division of responsibilities
• Without duplication (clones)
• Smooth evolution
• Maintainability

7. ATDD goals
• Acceptance TDD helps us keep our
product’s external quality on track by
giving it the correct features and
functionality.
• the system should meet what the
customer actually need.

8. Both sides of quality
************************************
• Then, we need to learn how to build the
thing right - TDD.
• Also, we need to learn how to build the
right thing - ATDD.

9. TDD and ATDD

10. Meeting needs with acceptance
TDD
Traditional way of
adding features
• Requirements – doc
• Implementation – sc
• Test design – tc
• Developer Test – rep.
• Acceptance test
Acceptance TDD
• Requirements – doc
• Test design – tc
• Implementation – sc
• Developer Test – rep
• Acceptance test

11. What is the difference?
• With ATTD we translate a requirement into a set
of executable tests and then do the
implementation against the tests rather than
against the developer’s interpretation of a verbal
requirement.
• Rather than working off of arbitrary requirements
documents, in acceptance TDD we strive for
close collaboration and defining explicit,
unambiguous tests that tell us exactly what it
means when we say a feature is “done.”

12. Close relationship
• TDD and acceptance TDD often go hand
in hand. On the system level, we run our
development process with acceptance
TDD; and inside the implementation step
of each feature; we employ TDD.

13. Benefits?
• No more long debugging sessions
– Each test case corresponds to a feature of the
system
– Test cases support refactoring
• More time for other stuff
– Reduce time of debugging sessions
– Reduce time fixing bugs
– Reduce rework due to misunderstandings
regarding requirements

14. Benefits?
• Feeling confident with my work
– The better your test suite is, the better the
quality of your code and the more confident
you can be about any changes you make. The
more confident you are about the changes
you make, the more changes you dare to
make. The more changes you make, the
better your internal quality becomes, the
easier it is to write tests for your code, and so
on. (a virtuous cycle)

15. Build it right: TDD
• TDD is a development and design
technique that helps us build up the
system incrementally, knowing that we’re
never far from a working baseline.
• A test is our way of taking that next small
step.

16. Build it right: TDD
• Test-Code-Refactor

17. Build it right: TDD
• Test-Code-Refactor
The term refactoring is used to better
communicate that the last step is about
transforming the current design toward a
better design.

18. First we write a test
• We are writing a test. Also, we are making
design decisions:
– We are designing the API—the interface for
accessing the functionality we’re testing.
– The test case that we design will be the first
“client” of the functionality that we are going
to implement.
– One of the fundamental lessons in designing
an interface is that we only evaluate a design
effectively and objectively when we try to use
it.

19. Then we write just enough code
• The second step of the TDD cycle is to
write just enough code to make the test
pass.
• You’re satisfying an explicit, unambiguous
requirement expressed by a test.

20. And then we refactor
• Take a step back, look at our design, and
figure out ways of making it better.
• It is all about keeping your software in
good health—at all times.
• Refactoring is about applying refactorings
on code in a controlled manner

21. Keeping code healthy with
refactoring
• “a disciplined technique for restructuring
an existing body of code, altering its
internal structure without changing its
external behavior” : Martin Fowler

22. Refactoring Example
• Replace Inheritance with Delegation
– Motivation: A subclass uses only part of a
superclass interface or does not want to
inherit data
– Summary: Create a field for the superclass,
adjust methods to delegate to the
superclass, and remove the subclassing.

23. Refactoring Example

24. Refactoring Example
•
Mechanics
1. Create a field in the subclass that refers to
an instance of the superclass. Initialize it to
this.
2. Change each method defined in the
subclass to use the delegate field.
3. Compile and test after changing each
method.

25. Refactoring Example
•
Mechanics
4. Remove the subclass declaration and
replace the delegate assignment with an
assignment to a new object.
5. For each superclass method used by a
client, add a simple delegating method.
6. Compile and test.

26. Refactorings alter internal
structure
• Many of the refactorings are very low-level
– rename method
– Rename variable
• Low-level refactorings are the fundamental
building blocks to achieving larger
refactorings
– Moving the responsibilities around in your
code
– Introducing or removing an inheritance
hierarchy

27. Refactorings preserve behavior
• whatever transformations you apply to the
existing code, those transformations
should only affect the code’s design and
structure—not its externally visible
behavior or functionality.
– Renaming a method that is part of a class’s
public interface - ???
– how can we be sure that our refactorings
haven’t changed the code’s external
behavior? - ???

28. The big picture of developing
software in small increments.

29. The big picture of developing
software in small increments.

30. Acceptance TDD
• Acceptance tests are indicators of the
completion of a requirement or feature.
• When all acceptance tests for a
requirement or feature are passing, you
know you’re done.

31. Advantages of ATDD
• Close collaboration
– Seeing concrete, working software
– Building trust and confidence
– Customer in control
– Evolving a shared language
• Tests as a shared language
– Tests as specification
– Specification by example

32. Tools for test-driven
development
• Unit-testing with xUnit
– Provides supporting code for writing unit tests,
running them, and reporting the test results.
• Test frameworks for acceptance TDD
– Tools for enhancing collaboration in software
development. (Fit and Fitnesse)
– They enable customers, testers, and programmers to
learn what their software should do, and to
automatically compare that to what it actually does
do.
– They compare customers' expectations to actual
results.

33. FitNesse
• FitNesse is a lightweight, open-source
framework that makes it easy for software
teams to:
– Collaboratively define Acceptance tests -- web
pages containing simple tables of inputs and
expected outputs.
– Run those tests and see the results
• http://fitnesse.org/

34. Tools for test-driven
development
• Continuous integration and builds
– On the one hand, running the full test suite
often takes too long (several minutes—even
hours) for a developer to wait for the green
bar.
– On the other hand, most of the tests are
unlikely to have been affected by the
developer’s recent changes

35. Tools for test-driven
development
• Continuous integration and builds

36. Build servers galore
• Cruise-Control (http://cruisecontrol.sf.net)
• AntHill (http://www.urbancode.com)
• Continuum (
http://maven.apache.org/continuum)
• Bamboo (
http://www.atlassian.com/software/bamboo/
)

37. Continuous Integration references
• More about the philosophy behind
continuous integration and the associated
tools:
– http://www.martinfowler.com/articles/continuo
usIntegration.html.
– http://www.jamesshore.com.

38. Tools for test-driven
development
• Code coverage
– In short, code coverage is a measurement of
how thoroughly our automated tests exercise
the production code and its source code
statements, branches, and expressions.
– http://www.javaranch.com/newsletter/200401/Intro

39. Tools for test-driven
development
• Code coverage
– This can be especially helpful when a team is
just starting to write unit tests or adopting
TDD, because it helps pointing out areas of
the code base that are not getting tested as
thoroughly as other parts of the code.

40. Tools for test-driven
development
• Code coverage tools for java
– Cenqua Clover (
http://www.cenqua.com/clover)
Cobertura (http://cobertura.sf.net)
EMMA (http://emma.sf.net)