This document provides an introduction to test-driven development (TDD). It discusses the benefits of unit testing over end-to-end testing, including error localization, execution time, tighter feedback loops, and test coverage. It defines what constitutes a unit test and what does not. Examples of difficult scenarios to unit test are given. The basic TDD cycle of writing a failing test, making the test pass, and refactoring is explained. An exercise demonstrates applying TDD principles. Mock objects and the differences between the Chicago and London schools of TDD are briefly covered. Finally, additional resources on TDD are listed.

1. An Intro to Test Driven
Development (TDD)
Rob Hale
April 11, 2016

2. Goals
• Automated testing isn’t (always) TDD
• Where it fits
• Moq

3. Automated Unit
Testing

4. What’s a “unit”
• The test operates in isolation
• tests should never depend on each other

5. Benefits of unit tests over end-to-end tests
• Error localization
• Execution time
• Tighter feedback loop
• Coverage

6. 40x

7. What’s not a unit test?
I like Michael Feathers’ explanation from Working Effectively with Legacy Code.
It’s not a unit test if:
• It talks to a database
• It communicates across a network
• It touches the file system
• You have to do special things to your environment to run it (like editing a
config file)

8. DIFFICULT
SCENARIOS TO
UNIT TEST
Closed Object Models
(Sharepoint, Silverlight)
Client – server architecture
- Communicating Across a Network
An out-of-process call
- Includes talking to databases and
Web Services
UI/GUI interaction
Touching the File System
Legacy Code
Requires the Environment to be
configured

9. Test Driven
Development
The basic cycle
Write a
failing test
Make the
test pass
Refactor

10. Put another way...
New
require
ment
Run
Tests
Write
new
test
Write
new
test
Write
new
code
Run
Tests
Refact
or
Make it Better
Make it Fail
Make it Work

11. “When you first start at doing TDD you know what the design should be. You
know what code you want to write. So you write a test that will let you write that
bit of code.
“When you do this you aren't really doing TDD – since you are writing the code
first (even if the code is only in your head )
“It takes some time to realize that you need to focus on the test. Write the test
for the behavior you want - then write the minimal code needed to make it pass
- then let the design emerge through refactoring. Repeat until done.”
--Brian Rasmussen
http://www.slideshare.net/baronslideshare/testdriven-development-tdd

12. An Exercise in
Test Driven
Development
The idea here is going to be to go
through the exercise of designing a
portion of a new solution in real
time.
After the exercise I want to circle
back and point out the benefits we
gained from the test first approach
which may have been missed had
we coded and then wrote tests.

13. Principles
• Think About What You Are Trying To Do
• Follow The TDD Cycle
• Never Write New Functionality Without A
Failing Test
- Each test should be for a single
concept
• Continually Make Small, Incremental
Changes
• Keep The System Running At All Times
- No one can make a change that breaks the
system
- Failures Must Be Address Immediately
• Is an activity of the developer
• Test code should be treated the same as
“production”
- maintained
- refactor
- source control
• Experimentation
- Names don’t matter initially
• When you want to change existing code,
first write covering, white box, unit tests
and then use TDD to add new
functionality
• Fix it in the simplest way possible using
as many assumptions as you like

14. TDD gives you
Design
Confidence
Documentation
Feedback

15. Realizing quality improvement through test driven development
Metric Description IBM:
Drivers
MSFT:
Windows
MSFT:
MSN
MSFT:
VS
Defect density of
non-TDD team
W X Y Z
Defect density of
team using TDD
0.61W 0.38X 0.24Y 0.09Z
% increase in
coding time
because
of TDD
[Management
estimates]
15-20% 25-35% 15% 25-30%
http://research.microsoft.com/en-us/groups/ese/nagappan_tdd.pdf

16. Visualized another way...
http://research.microsoft.com/en-us/groups/ese/nagappan_tdd.pdf

17. Moq

18. What’s a mock object?
A Test Double object that is pre-programmed with expectations which form a
specification of the calls they are expected to receive
The nice thing about using mocks while doing TDD is we can mock something
that doesn’t actually exist. Just define an interface and mock that. Later on we
can create concrete implementations of the interface (through TDD, of course)

19. Chicago vs London
Ledger
● Calculate(string expression)
Calculator
● Add
● Subtract
● Multiply
● ...
Based on http://programmers.stackexchange.com/a/123672
ledger.Calculate("5 * 7")

20. [TestFixture]
public class LedgerTests
{
public static Ledger Ledger { set; get; }
public static int Value { get; set; }
public static Mock<ICalculator> calculator;
[SetUp]
public void LedgerSetup()
{
calculator = new Mock<ICalculator>();
Ledger = new Ledger(calculator.Object);
}

21. Chicago vs London
[Test]
public void ChicagoStyle()
{
Value = Ledger.Calculate("5 * 7");
Assert.AreEqual(35, Value);
}
The Chicago/State school would have you assert whether the result is 35. The jUnit/nUnit frameworks are generally geared
towards doing this.

22. Chicago vs London
[Test]
public void ChicagoStyle()
{
Value = Ledger.Calculate("5 * 7");
Assert.AreEqual(35, Value);
}
The Chicago/State school would have you assert whether the result is 35. The jUnit/nUnit frameworks are generally geared
towards doing this.
[Test]
public void LondonStyle()
{
calculator.Verify(calc => calc.Multiply(5, 7), Times.Exactly(1));
}
The London/Interaction school would have you assert whether Calculator.Multiply(5,7) got called. The various
mocking frameworks are useful for this, and it can be very useful if, for example, you don't have ownership of the "Calculator"
object (suppose it is an external component or service that you cannot test directly, but you do know you have to call in a
particular way).

23. Resources
• http://www.slideshare.net/dehringer/test-driven-development-5785229
• http://www.slideshare.net/baronslideshare/testdriven-development-tdd
• http://research.microsoft.com/en-us/groups/ese/nagappan_tdd.pdf
• http://www.martinfowler.com/articles/mocksArentStubs.html
• Video: Llewellyn Falco & Woody Zuill - Practical Refactoring
• https://youtu.be/aWiwDdx_rdo
• Video: Raymond Lim & Roy Osherove - TDD Pairing Session 1
• https://youtu.be/xX9hfPkA800
• Video: Doc Norton - The Technical Debt Trap
• https://vimeo.com/97507576

24. Other resources mentioned by attendees
The following resources were mentioned after the presentation. They require
purchase or subscription.
• Play by Play: TDD with Brad Wilson (Pluralsight)
• https://www.pluralsight.com/courses/play-by-play-wilson-tdd
• Automated Testing for Fraidy Cats Like Me with Julie Lerman (Pluralsight)
• https://www.pluralsight.com/courses/automated-testing-fraidy-cats
• Test-Driven Development training by Mike Hill & Joshua Kerievsky (Industrial
Logic)
• https://elearning.industriallogic.com/gh/submit?Action=AlbumContentsAction&album=before
&devLanguage=Java