Effective Unit Testing with Test Doubles (GDG Boulder, June 2016)

Matt Logan
Effective Unit Testing
with Test Doubles

View Slide

• Terminology
• Test philosophy
• Types of test doubles
• Best practices
• Full example
• Extra considerations
Outline

View Slide

• System under test
• Depended-on component
• Indirect output
• Indirect input
• Test double
Terminology

View Slide

–Martin Fowler
“Test Double is a generic term for any case
where you replace a production object for
testing purposes.”

View Slide

Why?
• Enable testing
• Ease testing
• Improve testing
• NOT just to “isolate” system under test

View Slide

Test philosophy
• Tests should:
• Verify correct behavior (or state)
• Allow for safe refactoring
• Drive good design
• Serve as documentation
• Be easy to write!

View Slide

• Dummy
• Fake
• Stub
• Mock
• Spy
Types of test doubles

View Slide

Dummies
• Never used
• Satisfy method parameters
• Easy to implement
• Primitives or objects

View Slide

Dummies
class DummyClient
implements LocationClient { 
 
@Override
public void startUpdates(Callback c) { 
throw new RuntimeException("Dummy!"); 
} 
}

View Slide

Dummies
• More examples
• -1
• “String that will not be used”
• null

View Slide

Fakes
• Replace a “depended-on component” with a lighter
weight implementation
• Takes shortcuts, but still functional
• Can be used for input or output
• Usually hand-coded
• Example: in-memory database
• Another example: fake web service

View Slide

Fakes
class FakeDb implements LocationDatabase { 
Map map = new HashMap<>(); 
 
@Override 
public void save(String key, Location loc) { 
map.put(key, loc); 
} 
 
@Override 
public Location get(String key) { 
return map.get(key); 
} 
}

View Slide

Stubs
• Control indirect inputs to system under test
• Provide “canned responses”
• Example: stubbed HTTP responses

View Slide

Stubs
class LocationEnabledDevice 
implements DeviceInfo { 
 
@Override 
public boolean isLocationEnabled() { 
return true; 
} 
}

View Slide

Stubs
// Create the “mock”
DeviceInfo deviceInfo =
mock(DeviceInfo.class);
// “Stub” its method(s) 
when(deviceInfo.isLocationEnabled())
.thenReturn(false);

View Slide

Mocks
• Mocks “expect”
• Good for verifying exact behavior
• Good for strict TDD
• Can lead to over-speciﬁcation
• Also a generic (confusing) term for any test double
• Also a verb for creating a test double

View Slide

Mocks
// Create system under test with mock
object
expect(callbacks
.onLocationUnavailable());
// Exercise system under test
// Will throw if method not called

View Slide

Spies
• Very similar to mocks
• Record interactions, “verify” later
• Better at showing intent — can hide irrelevant calls
• Debugging can be harder

View Slide

Spies
// Create system under test with spy
// Exercise system under test
verify(callbacks)
.onLocationUnavailable();
// Will throw if method not called

View Slide

Best practices
• Don’t use doubles for values!
• Examples: Location, Date, Employee
• Just create them
• Don’t need to verify that accessors are called
• If object creation is complicated, try builders

View Slide

Best practices
• Don’t use doubles for classes — just interfaces!
• Interfaces show relationships between objects
• Extract “what you need” into an interface
• Need interfaces to create hand-coded doubles

View Slide

Best practices
• Don’t test implementation details!
• Ask question: “Is this is a required behavior?”
• Leads to brittle, unreliable tests
• Refactoring implementation without changing API
should NEVER break tests.

View Slide

Location Tracker
github.com/mattlogan/locationtracker

View Slide

public void trackLocation() { 
if (!device.isLocationEnabled()) { 
callbacks.onLocationUnavailable(); 
return; 
} 
 
client.startUpdates(new Callback() { 
@Override 
public void onUpdate(Location curLoc) { 
if (!curLoc.equals(lastLoc)) { 
callbacks.onChange(curLoc); 
} 
lastLoc = curLoc; 
} 
}); 
}

View Slide

class DummyClient
implements LocationClient { 
 
@Override
throw new RuntimeException("Dummy!"); 
} 
}

View Slide

class NoLocationDevice 
 
@Override 
return false; 
} 
}

View Slide

@Test 
public void locationUnavailableCalled() { 
DeviceInfo device = // Stub
new NoLocationDevice(); 
LocationClient client = // Dummy
new DummyClient(); 
Callbacks callbacks = // Spy
mock(Callbacks.class); 
LocationChangeTracker tracker = 
new LocationChangeTracker(device, 
client, 
callbacks); 
tracker.trackLocation(); 
verify(callbacks)
.onLocationUnavailable(); 
}

View Slide

public void trackLocation() { 
if (!device.isLocationEnabled()) { 
callbacks.onLocationUnavailable(); 
return; 
} 
 
client.startUpdates(new Callback() { 
@Override 
public void onUpdate(Location curLoc) { 
if (!curLoc.equals(lastLoc)) { 
callbacks.onChange(curLoc); 
} 
lastLoc = curLoc; 
} 
}); 
}

View Slide

class FakeClient implements LocationClient { 
List locs = new ArrayList<>(); 
 
FakeClient(Location... locs) { 
Collections.addAll(this.locs, locs); 
} 
 
@Override 
for (Location loc : locs) { 
c.onUpdate(loc); 
} 
} 
 
@Override 
public void stopUpdates() {} 
}

View Slide

class LocationEnabledDevice 
 
@Override 
return true; 
} 
}

View Slide

@Test 
public void onChangeCalled() { 
DeviceInfo device = // Stub 
new LocationEnabledDevice(); 
LocationClient client = // Fake 
new FakeClient(new Location(1, 0), 
new Location(2, 2), 
new Location(2, 2)); 
Callbacks callbacks = // Spy 
mock(Callbacks.class); 
LocationChangeTracker tracker = 
new LocationChangeTracker(device, 
client, 
callbacks); 
tracker.trackLocation(); 
verify(callbacks, times(2)) 
.onChange(isA(Location.class)); 
}

View Slide

Extra considerations
• Testing behavior vs. testing state
• Test doubles aren’t just for “unit” tests
• Dependency injection helps
• Fakes can become production objects
• It’s okay to write tests for your test doubles

View Slide

Contact + resources
• Contact & follow me (if you want to)
• [email protected]
• @_mattlogan
• mattlogan.me
• More resources
• github.com/mattlogan/locationtracker
• Mocks Aren’t Stubs - Martin Fowler
• Mocks Aren’t Stubs, Dummies, Fakes or Spies - Dave Marshall
• xUnit Test Patterns - Gerard Meszaros

View Slide

Effective Unit Testing with Test Doubles (GDG Boulder, June 2016)

Effective Unit Testing with Test Doubles (GDG Boulder, June 2016)

Matt Logan

More Decks by Matt Logan

Other Decks in Programming

Featured

Transcript