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

  • If a test name has "and" in it, you're probably testing more than one thing
  • Don't put logic into tests, it is a frequent source of pain
  • Write clear failure messages, consider using existing libraries and frameworks
  • It's ok if some tests are DRY, but prefer DAMP (Descriptive And Meaningful Phrases) - a bit of duplication for verbosity and understanding
  • Instead of hard coding values into tests (ACCT_BALANCE="$20") use helper methods (builder pattern) and tools to generate the necessary data instead because hard coding doesn't explain why a value was chosen in the first place
  • Setup or initialization of the test environment can hide details and gloss over things that should be tested, beware
  • The best validation helper methods assert a single fact, not multiple (does not test multiple things)
  • In summary:
    • Test state, not interactions
    • Test behaviors, not methods/functions
    • Aim for unchanging tests
    • Test via public APIs
    • Make tests complete and concise
    • Structure tests to emphasize behaviors
    • Name tests after the behavior being tested
    • Don't put logic into tests
    • Write clear failure messages
    • Follow DAMP over DRY when sharing code for tests



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