Test Doubles Mock Objects & Design Principles SWE-795, Test Driven Development, GMU Spring 2011 – Bill Shelton
May 20, 2015
Test Doubles Mock Objects & Design Principles
SWE-795, Test Driven Development, GMU Spring 2011 – Bill Shelton
“Once”, the Mock Turtle said at last, with
a deep sigh, “I was a real
turtle.”
Lewis Carroll, Alice’s Adventure in Wonderland
Types of Test Doubles
• Gerard Meszaros, xUnit Test Patterns, http://xunitpatterns.com/Test%20Double%20Patterns.html
• Fakes, Stubs, Mocks, Spies, Dummies, etc.• Fowler draws lines between mocks and stubs,
yet “mocking” tools do both.• Let’s just call these “Mocks” and classify how
they behave and how they’re used
Problems Mocks solve
• Test-time dependency related problems– Slow tests– Unavailable services or objects– Lack of isolation and control over collaborating objects– *Side Effects (Koskela or Fowler don’t emphasize this)
• Verifying interaction between object under test (or SUT) and collaborators
• Can drive the definition of unknown types– Need Driven Development (Nat Pryce, Steve Feeman)– #goos http://www.growing-object-oriented-software.com/
Ways to build Mocks
• Code by hand (Fakes)– Extend the depended-upon object and override
methods– Build lightweight representations; e.g.,
anonymous classes– What does this smell like?
• On-the-fly with a mocking framework– Lots to choose from– Almost all have some limitations
State and Behavior Verification
• State-based tests assert the resultant state of an operation on the object under test
• Behavior-based tests verify how the object under test interacts with its collaborators
• Should these be considered mutually exclusive activities?
<code/>: https://gist.github.com/840494
Classicists and Mockists(Fowler)
• Coupling to Implementation: Classicists think it’s important to only think about the external interface, whereas Mockists must consider the implementation …– What about considering various paths in state-based tests?
Classicist do need to look beyond the interface. This is a design activity.
• Test Isolation: Fowler seems to imply that this is less important to state-based tests
• * Test Driven Design Idioms (Let’s see some case studies)– Outside-in vs. Middle-out– “Tell Don’t Ask”– Law of Demeter, or nearest neighbor principle
Discovering New Types
• Freeman and Pryce describe Need-Driven Development as an outside-in approach
• Thinking in terms of layers, starting with the outside first, build inwards using Mock Objects to discover interface needs– An interesting Agile idea, but in practice how does
it work? Case study?• Process: Refer to earlier Dependency Slide– Collaborators evolve and become SUT
Summary
• Mocks can be used for:– Managing test-time dependencies (databases, network
services, email, etc.)– Verifying how the object under test interacts with its
collaborators– Driving an outside-in design process
• Discovery of new types
• Other points– Decouple dependencies in code to allow injection of
mocks; e.g., setCollaborator(Collaborator c) – Consider control and isloation
Other Applications for Mocks?
• It appears that Mocks have only been considered as an aid to testing, design, and TDD. If Mocks can simulate behavior, could they be used for other purposes?
• Software simulation– Simulate faulty behavior or state …
• Mutant behavior– Given a known behavior of the application of a specific
mutant operator, could we simulate that using Mock Objects?
Some mocking frameworks
• Java– jMock, EasyMock, PowerMock, jMockit, Mockito
• .NET– NMock, moq, EasyMock.NET, Rhino Mocks
• Python– Pymox, dingus
• ColdFusion– MightyMock (part of MXUnit), MockBox, ColdMock,
CFEasyMock• Ruby
– rr, mocha, flexmock, stump, facon
Geeky Chuck Norris Jokes
• Chuck Norris can divide by Zero.
• Chuck Norris can count to infinity … twice!
• Chuck Norris doesn’t do TDD. Bugs are too damn scared to go anywhere near his code.
Introduction to Software Testing (Ch 2) © Ammann & Offutt
Simple Round Trip Coverage
SRTCNode Coverage
NC
Edge Coverage
EC
Edge-Pair Coverage
EPC
Prime Path Coverage
PPC
Complete Path Coverage
CPC
Complete Round Trip Coverage
CRTC
All-DU-Paths Coverage
ADUP
All-uses Coverage
AUC
All-defs Coverage
ADC
Introduction to Software Testing (Ch 2) © Ammann & Offutt
Simple Round Trip Coverage
SRTCNode Coverage
NC
Edge Coverage
EC
Edge-Pair Coverage
EPC
Prime Path Coverage
PPC
Complete Path Coverage
CPC
Complete Round Trip Coverage
CRTC
All-DU-Paths Coverage
ADUP
All-uses Coverage
AUC
All-defs Coverage
ADC
Chuck NorrisCoverage
CNC
TheChuck Norris
Criterion subsumes ALL othercriteria. Period. The End.