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

  • A "stub" returns exactly what you want it to, just returns the value you need
  • Interaction testing is sometimes known as mocking
  • Interaction testing tests interactions with the API, similar to a user
  • Prefer real-world testing over simulated environments if possible, it provides more confidence
  • Prefer real implementation testing if it's deterministic, fast, and has simple dependencies
  • Test doubles can speed up tests
  • Parallelization of tests helps speed up overall test time
  • Instead of manually creating an object to test against, instead use the same object construction code that is used in production
  • A large number of fakes can create huge engineering efficency gains
  • Fakes require domain experience to create as well as effort to maintain
  • Consider having the team that owns an API also own writing and maintaining a fake for use by other teams
  • A fake must have flawless fidelity (sameness) to the real thing, but only from the point of view of the tests
  • Fakes should report errors if a non-existent code path attempts to be tested
  • Use the same tests (contract tests) against the fake API and the real public API
  • If a fake is good enough, all tests can be run against it, no need to even touch the public / real API
  • To quickly create a fake, wrap all calls to the API in a single class then create a fake version of the class that does not talk to the API
  • Stubbing is a way to hard code responses



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