Software Engineering at Google Chapter #13 - Test Doubles (1 of 3)

  • A "test double" is an object or function that can stand in for a real implementation in a test
  • An example would be using a test double to quickly return dummy data instead of making a real connection to a real DB
  • Test doubles can be more consistent and less flakey than using the real implementations
  • In order to use test doubles a codebase needs to be designed to be testable - meaning things should be structured in such a way so you can easily switch out the real DB code with mock DB code
  • If a codebase is not designed to be testable it will make major effort to add test doubles
  • Compare test doubles to real implementations. For your use case, one may be less brittle than the other
  • Consider how close your test double is to the real thing (its "fidelity")
  • The closer a test double is to 100% fidelity the more effort it takes to maintain parity
  • Code bases have interia (think of a code's "culture" - tests vs no tests, consistent vs inconsistent, etc)
  • Example use case for test doubles: Test credit card data with a card that has expired
  • A "seam" is a way to make code testable by allowing for the use of test doubles
  • The purpose of the seam is to easily switch out the production code for test double code - attach and detatch at the seams
  • Dependency injection is a commonly used way of creating seams (automated frameworks exist, see Google Guice)
  • Overuse of mocking frameworks makes a codebase harder to maintain (more discussion later)
  • A software library that makes it easier to create test doubles is called a "mocking framework"
  • Mocking frameworks are useful because it reduces the amount of repetitive boilerplate that needs to be done each time
  • A "fake" is a lightweight implementation of an API that behaves like production but is used only for testing



Thank you for your time and attention.
Apply what you've learned here.
Enjoy it all.