Test driven development involves writing tests before writing code to make the tests pass. This ensures code is built to satisfy explicit requirements. The TDD process is: write a failing test, write code to pass the test, refactor code. This improves quality by preventing defects and ensuring code is maintainable through extensive automated testing. Acceptance TDD applies this process on a system level to build the right functionality.

1. Test Driven Development
INFO-6067

2. Test Driven Development
• “Only ever write code to fix a failing test.” That’s test-driven
development, or TDD, in one sentence.
• First - write a test,
• Then write code to make the test pass.
• Then design relying on the existing tests to keep from breaking things
while coding.

3. The Challenge
• Even after decades of advancements in the software industry, the
quality of software remains a problem
• There are two sides to quality problems:
• high defect rates
• lack of maintainability.
• Defects create unwanted costs by making the system unstable,
unpredictable, or potentially completely unusable.
• They reduce the value of software —sometimes to the point of creating
more damage than value.

4. Test Driven Development

5. The Challenge
• Well-written code exhibits good design and a balanced division of
responsibilities without duplication.
• Poorly written code doesn’t, and working with it is a nightmare in
many aspects:
• the code can be difficult to understand
• difficult to change.
• changing problematic code tends to break functionality elsewhere in the
system,
• duplication causes issues in the form of bugs that were supposed to be fixed
already.

6. The Challenge
• Testing has been established as a critical ingredient in software
development, but the way testing is traditionally performed— a
lengthy testing phase after the code is “frozen”—leaves much room
for improvement.
• The cost of fixing defects that get caught during testing is typically a
magnitude or two higher than if caught as they were introduced into
the code base.

7. Test Driven Development

8. TDD
• Test-code-refactor is the mantra test-driven developers like to chant.
• It describes succinctly what takes place

9. Solution
• Build the thing right.
• Build the right thing.
• Using Test Driven development and Acceptance TDD.
• On a lower level, we test-drive code using the technique called TDD.
• On a higher level—that of features and functionality— test-drive the system
using a similar technique called acceptance TDD

10. Test Driven
TDD is a technique for improving the software’s internal quality, whereas
acceptance TDD helps keep the product’s external quality on track by
giving it the correct features and functionality.

11. In Practice
• Traditionally we’ve always designed first, then implemented the
design, and then tested the implementation
• TDD turns this thinking around and says we should write the test first
and only then write code to reach that clear goal.
• Design is what we do last. We look at the code we have and find the
simplest design possible.
• The last step in the cycle is called refactoring.

12. Quality
• People tend to associate the word quality with the number of defects
found after using the software.
• Some consider quality to be other things such as the degree to which
the software fulfills its users’ needs and expectations.
• Some consider not just the externally visible quality but also the internal
qualities of the software in question (which translate to external
qualities like the cost of development, maintenance, and so forth).
• TDD contributes to improved quality in all of these aspects with its
design-guiding and quality-oriented nature.

13. Quality TDD
• TDD makes sure that there’s practically no code in the system that is
not required—and therefore executed—by the tests.
• Through extensive test coverage and having all of these tests
automated, TDD guarantees that whatever you have written a test for
works, and the quality (in terms of defects) becomes more of a
function of how well we succeed in coming up with the right test
cases.
• to build the thing right —with TDD

14. Quality ATDD
• With acceptance TDD, we’re just talking about tests for the behavior
of a system rather than tests for the behavior of objects. This means
that we need to speak a language that both the programmer and the
customer understand.
• Development on a higher level to help us meet our customers’
needs—to build the right thing—with acceptance TDD

15. Test Driven Development

16. Test Driven Development

17. Test Driven Development

18. Test Driven Development

19. Test Driven Development

20. Writing Tests

21. Test Driven Development

22. Refactoring

23. Refactoring
• Refactoring is a disciplined way of transforming code from one state
or structure to another, removing duplication, and gradually moving
the code toward the best design we can imagine.
• By constantly refactoring, we can grow our code base and evolve our
design incrementally.

24. TDD
Writing Tests

25. Programming by Intention
• When writing tests before the production code they’re
supposed to test, we face a dilemma: how to test something
that doesn’t exist without breaking our test-first rule. The
answer is as simple —imagine the code you’re testing exists!
• What are we supposed to imagine? We imagine the ideal shape
and form of the production code from this particular test’s
point of view.
• By writing our tests with the assumption that the production
code is as easy to use as we can imagine, we’re making it easy
to write the tests and we’re making sure that our production
code will become as easy to use as we are able to imagine.
• It has to, because our tests won’t pass otherwise.
• This is programming by intention.

26. Program by Intention
• The concept of writing code as if another piece of code exists—even
if it doesn’t—is a technique that makes us focus on what we could
have instead of working around what we have.
• Programming by intention tends to lead to code that flows better,
code that’s easier to understand and use—code that expresses what
it does and why, instead of how it does it.

27. Write the Code
• Write just enough code to make the test pass.
• Why just enough code? The test we’ve written is a test that’s failing.
It’s pointing out a gap between what the code does and what we
expect it to do. It’s a small gap, which we should be able to close in a
few minutes which, in turn, means that the code is never broken for
long.

28. Write the Code
• One of the fundamental ideas behind the concept of test-first
development is to let the tests show you what to implement in order
to make progress on developing the software.
• You code to satisfy an explicit, unambiguous requirement expressed
by a test.
• You’re making progress, and you’ve got a passing test to show for it.

29. Refactor
• Our main goal is to make the test pass as quickly as possible. That
often means an implementation that’s not optimal.
• We’ll take care of a sub-optimal design after we have the desired
behavior in place—and tests to prove it.
• With the tests as our safety net, we can then proceed to improving
the design in the last step of the TDD cycle: refactoring.

30. Refactor
• We take a step back, look at our design, and figure out ways of
making it better. The refactoring step is what makes TDD sustainable.
• Sustainable:
• able to be maintained at a certain rate or level.

31. Requirements to Tests
• How would tests drive the development of the system?
• Decompose the requirements
• slicing the requirements into a set of tests that, when passing, lead to the
requirements being satisfied.
• Translating requirements into tests is far superior to merely
decomposing requirements into tasks because tasks make it easy to
lose sight of the ultimate goal—the satisfied requirement.
• Tasks only give us an idea of what we should do.

32. A good Test
• A good test is atomic
• tests a small, focused, atomic slice of the desired behavior
• A good test is isolated
• test should be isolated from other tests so that, the test assumes nothing
about any previously executed tests.
• Remember F.I.R.S.T. ?
• Fast
• Isolated/independent
• Repeatable
• Self-validating
• Thorough/Timely

33. Run the failing test
• When we run our freshly written test, it fails—not surprisingly,
because none of the methods we added are doing anything.
• A failing test is progress.
• What we have now is a test that tells us when we’re done with that
particular task. Not a moment too soon, not a moment too late. It
won’t try to tell us something like “you’re 90% done” or “just five
more minutes.” We’ll know when the test passes; that is, when the
code does what we expect it to do.

34. Failing test
• Running the test, we get the output complaining about getting a null
when it expected the string “Hello, Reader”.
• We’re in the red phase of the TDD cycle, which means that we have
written and executed a test that is failing
• We’ve now written a test, programming by intention, and we have a
skeleton of the production code that our test is testing.
• At this point, all that’s left is to implement the Template class so that
our test passes and we can rest our eyes on a green progress bar.

35. Red Phase

36. Make our test pass.
• We don’t have much code yet, but we’ve already made a number of
significant design decisions. We’ve decided that there should be a
class Template that loads a template text given as an argument to the
constructor
• We can set a value for a named placeholder, and it can evaluate itself,
producing the wanted output.
• What’s next?
• We had already written the skeleton for the Template class so that
our test compiles.

37. Make it pass
• All the constructors and methods are in place to make the compiler
happy, but none of those constructors and methods is doing anything
so far.
• We want to make the test pass in the easiest, quickest way possible.
To put it another way, we’re now facing a red bar, meaning the code
in our workspace is currently in an unstable state.
• We want to get out of that state and into stable ground as quickly as
possible.

38. How to make it pass simply?
• How do we make the test pass as quickly and easily as possible?
• Evaluating a template that simple, “Hello, ${name}”, with a string-
replace operation would be a matter of a few minutes of work,
probably.
• There’s another implementation, however, of the functionality
implied by our failing test that fits our goal of “as quickly as possible”
a bit better.

39. First try
public class Template
{
public Template(String templateText) {
}
public void set(String variable, String value) {
}
public String evaluate()
{
return "Hello, Reader";
}
}

40. Not optimum
• Hard-coding the evaluate method to return “Hello, Reader” is most
certainly the quickest and easiest way to make the test pass.
Although it may not make much sense at first.
• We want to squeeze out the wanted behavior with our tests. In this
case, we’re making use of neither the actual variable nor the
template.
• And that means we know at least two dimensions on which to push
our code toward a proper implementation.
• Let’s extend our test to squeeze out the implementation we’re
looking for.

41. Second try
public class TestTemplate
{
@Test
public void oneVariable() throws Exception {
Template template = new Template("Hello, ${name}");
template.set("name", "Reader");
assertEquals("Hello, Reader", template.evaluate());
}
@Test
public void differentValue() throws Exception {
Template template = new Template("Hello, ${name}");
template.set("name", "someone else");
assertEquals("Hello, someone else", template.evaluate());
}
}

42. Triangulate
• We’ve added a second call to set—with different input—and a second
assertion to verify that the Template object will re-evaluate the template
with the latest value for the “name” variable.
• Our hard-coded evaluate method in the Template class will surely no
longer pass this test, which was our goal.
• This technique is named triangulation, referring to how we’re using
multiple bearings to pinpoint the design toward the proper
implementation.
• Now, how could we make this enhanced test pass?

43. Another pass
public class Template
{
private String variableValue;
public Template(String templateText) {
}
public void set(String variable, String value) {
this.variableValue = value;
}
public String evaluate() {
return "Hello, " + variableValue;
}
}

44. Are we refactoring?
• Our test passes again with minimal effort.
• Obviously our test isn’t good enough yet, because we’ve got that
hard-coded part in there, so let’s continue triangulating to push out
the last bits of literal strings from our code.
• The next shows how we alter our test to drive out not just the hard-
coding of the variable value but also the template text around the
variable.

45. Closer?
public class TestTemplate {
@Test
public void oneVariable() throws Exception {
Template template = new Template("Hello, ${name}");
template.set("name", "Reader");
assertEquals("Hello, Reader", template.evaluate());
}
@Test
public void differentTemplate() throws Exception {
Template template = new Template("Hi, ${name}");
template.set("name", "someone else");
assertEquals("Hi, someone else", template.evaluate());
}}

46. Red result
• Red bar. Obviously the hard-coded return statement doesn’t cut it
anymore. At this point, we’re facing the task of parsing the template
text somehow.
• Perhaps we should first implement the parsing logic and then come
back to this test.
• Time to discuss breadth and depth.