Software Engineering at Google Chapter #12 - Unit Testing (2 of 3)

  • Mocks are brittle, prefer to use real data sources so long as they are fast and deterministic
  • Test failures happen for two reasons: The test itself is flawed or the system under test is incomplete or has a problem
  • Ensure that tests fail clearly so engineers can quickly troubleshoot
  • Clear tests scale
  • Tests outlast the engineers who wrote them and the tests exist for a purpose
  • A test is "complete" when it's body contains all the information a reader needs to understand the test
  • A test is "concise" when it contains no irrelavant or distracting information
  • It can be worth violating DRY when it comes to completness and conciseness in testing
  • Test behaviors, not methods
  • Rather than writing a test for each method, write a test for each behavior
  • A "behavior" is any guarantee a that a system makes about how it will respond to a series of inputs while in a particular state"
  • Every behavior-based test has three components: given, when, and then. Write using this template
  • Behaviors are expressed via testing terms given (given X is NOTNULL), when (when state = foo), and then (if X then do Y)
  • Example: Given that the bank account is empty, when attempting to withdraw money from it, then the transaction is rejected
  • Behavior tests are more like reading natural language, they clearly show cause and effect, and it easily shows what is being tested, thus it discourages duplicate tests
  • Tests should be coupled to behaviors, not methods
  • Each test should only cover a single behavior and should only require one "when" and "then" block
  • A test's name should summarize the behavior its testing
  • Verbose test names are ok because it's important that it be very readable and it will rarely be typed (unlike a method call)
  • Start behavior-based test named with "should" (shouldNotAllowTransactionIfBalanceIsLessThanZero)



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