Skip to main content
Test Double company logo
Services
Services Overview
Holistic software investment consulting
Software Delivery
Accelerate quality software development
Product Management
Launch modern product orgs
Legacy Modernization
Renovate legacy software systems
DevOps
Scale infrastructure smoothly
Upgrade Rails
Update Rails versions seamlessly
Technical Recruitment
Build tech & product teams
Technical Assessments
Uncover root causes & improvements
Case Studies
Solutions
Accelerate Quality Software
Software Delivery, DevOps, & Product Delivery
Maximize Software Investments
Product Performance, Product Scaling, & Technical Assessments
Future-Proof Innovative Software
Legacy Modernization, Product Transformation, Upgrade Rails, Technical Recruitment
About
About
What's a test double?
Approach
Meeting you where you are
Founder's Story
The origin of our mission
Culture
Culture & Careers
Double Agents decoded
Great Causes
Great code for great causes
EDI
Equity, diversity & inclusion
Insights
All Insights
Hot takes and tips for all things software
Leadership
Bold opinions and insights for tech leaders
Developer
Essential coding tutorials and tools
Product Manager
Practical advice for real-world challenges
Say Hello
Test Double logo
Menu
Services
BackGrid of dots icon
Services Overview
Holistic software investment consulting
Software Delivery
Accelerate quality software development
Product Management
Launch modern product orgs
Legacy Modernization
Renovate legacy software systems
Cycle icon
DevOps
Scale infrastructure smoothly
Upgrade Rails
Update Rails versions seamlessly
Technical Recruitment
Build tech & product teams
Technical Assessments
Uncover root causes & improvements
Case Studies
Solutions
Solutions
Accelerate Quality Software
Software Delivery, DevOps, & Product Delivery
Maximize Software Investments
Product Performance, Product Scaling, & Technical Assessments
Future-Proof Innovative Software
Legacy Modernization, Product Transformation, Upgrade Rails, Technical Recruitment
About
About
About
What's a test double?
Approach
Meeting you where you are
Founder's Story
The origin of our mission
Culture
Culture
Culture & Careers
Double Agents decoded
Great Causes
Great code for great causes
EDI
Equity, diversity & inclusion
Insights
Insights
All Insights
Hot takes and tips for all things software
Leadership
Bold opinions and insights for tech leaders
Developer
Essential coding tutorials and tools
Product Manager
Practical advice for real-world challenges
Say hello
Developers
Developers
Developers
Testing

Mock objects in discovery tests

Justin Searls provides an intro to a variant of TDD sometimes described as "London style," "Mockist," "Outside-in," "Isolation," and "GOOS.” The screencast may provide you with a clearer picture about what some people who talk about mock objects in a positive light are actually talking about.
Justin Searls
|
May 14, 2014
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

This screencast is a very cursory introduction to a variant of TDD that’s described as everything from “London style” to “Mockist”, “Outside-in”, “Isolation”, and “GOOS”. I’ve recently started calling it “Discovery Testing” to emphasize its intended benefit and distance it from the now too-conflated-to-be-useful term “unit test”. Since none of those other names have stuck, perhaps this one will.

The screencast may provide you with a clearer picture about what some people who talk about mock objects in a positive light are actually talking about. My goal is to illustrate and demonstrate their very narrow (but well-defined) purpose in this alternative approach to TDD. Our use of mock objects is fundamentally different from how they’re used by most well-published practitioners of TDD, but both tribes tend to confuse the community by using the same language to describe differently-motivated activities.

A lot of criticism about mock objects (e.g. mocks returning mocks, mocks reducing confidence in a test’s value, mocks that produce fantasy green tests) simply have no bearing on discovery testing as I practice it. Each of those symptoms suggest a wildly different (and less valuable, in my opinion) approach to mock objects which—depressingly—also represents the vast majority of their use.

If you haven’t yet, please read Gary’s post on test isolation this morning. I agree with Gary wholeheartedly. As much as I love how test doubles provide a mechanism to accomplish a workflow that I really enjoy using, I only use mocks to the extent I need them to specify the contract between a subject’s dependencies. The real goal of discovery testing is to quickly reduce the scope of a problem and expose a rich harvest of leaf nodes in the object graph. Leaf nodes that have no dependencies and implement pure functions are easy to test, maintain, and understand. As a result, the name of the game is to maximize the leaf nodes in your object graph and minimize the collaborators. I tend to write a deep and wide tree with lots of collaborators when reducing a very complex task, and I tend to arrive at much flatter trees when the task is either simple or well-understood.

Here are some links to things covered or mentioned in the screencast:

  • The screencast’s example code
  • GOOS
  • Beck, DHH, Fowler TDD Hangout
  • Uncle Bob’s recent post on mocking
  • Uncle Bob’s other recent post on mocking
  • Gary Bernhardt’s post on test isolation
  • jasmine-given
  • node-sandboxed-module
  • jasmine-stealth

Related Insights

🔗
How to stop hating your tests
🔗
Breaking up (with) your test suite
🔗
Please don't mock me
🔗
Please mock me

Explore our insights

See all insights
Leadership
Leadership
Leadership
Audentes Fortuna Iuvat: being bold amidst uncertainty

What should businesses do in the face of uncertainty? This is not the first time leaders are dealing with strange economic environments, and it won’t be the last.

by
Ed Frank
Developers
Developers
Developers
LLMallard: the low-key AI chat bot you secretly need

The most perfect dev workflow for taking advantage of deeply powerful AI tooling that’s hyper efficient on token usage with minimal API calls—and the perfect pair programming partner.

by
Daniel Huss
Leadership
Leadership
Leadership
Why we coach the system, not just the team

Slow delivery isn’t usually about your people—it’s about your system. Shifting focus to incremental improvements in the system helps change not just processes but behaviors for lasting change.

by
Doc Norton
Letter art spelling out NEAT

Join the conversation

Technology is a means to an end: answers to very human questions. That’s why we created a community for developers and product managers.

Explore the community
Test Double Executive Leadership Team

Learn about our team

Like what we have to say about building great software and great teams?

Get to know us
No items found.
Test Double company logo
Improving the way the world builds software.
What we do
Services OverviewSoftware DeliveryProduct ManagementLegacy ModernizationDevOpsUpgrade RailsTechnical RecruitmentTechnical Assessments
Who WE ARE
About UsCulture & CareersGreat CausesEDIOur TeamContact UsNews & AwardsN.E.A.T.
Resources
Case StudiesAll InsightsLeadership InsightsDeveloper InsightsProduct InsightsPairing & Office Hours
NEWSLETTER
Sign up hear about our latest innovations.
Your email has been added!
Oops! Something went wrong while submitting the form.
Standard Ruby badge
614.349.4279hello@testdouble.com
Privacy Policy
© 2020 Test Double. All Rights Reserved.