Software Engineering at Google Book Notes

Chapter 12: Unit Testing



  • A unit test is maintainable when

    • they "just work" after writing them
    • you don't have to think about them until they fail and those failures indicate real bugs
    • the tests will outlive you.
  • Unit tests shouldn't change when

    • there's a refactor
    • new features are added
    • there's a bug fix (it's like adding a new feature)
  • Unit tests should change when

    • behavior changes
  • To prevent brittle tests you should

    • test via public APIs

      • testing private APIs results in many brittle tests
      • How do you know if it's a public API?

        • helper method or helper classes? are public APIs
        • packages or classes accessible to anyone? are public APIs
    • test state, not interactions

      • usually tests test interactions
      • Tests that test interactions won't work because the interaction can cause a side-effect and fail the test
      • Instead, test the state after the interaction happens
      • Example (from the book)

        • Test that tests interaction

            public void shouldWriteToDatabase() {
        • Test that tests state

          public void shouldCreateUsers() {
  • To write clearer tests

    • Make your tests complete and concise

      • A test can fail for two reasons

        • 1. the system is incomplete
        • 2. the test itself is flawed
      • Tests should be complete

        • All of the relevant context and information should be in the test itself
      • Tests should be concise

        • There shouldn't be any irrelevant or distracting information
      • How to

        • Don't pass a lot of irrelevant information into the constructor
        • Don't heavily rely on helper methods
        • A bad example

          public void shouldPerformAddition() {
            Calculator calculator = new Calculator(new RoundingStrategy(), "unused", ENABLE_COSINE_FEATURE, 0.01, calculusEngine, false);
            int result = calculator.calculate(newTestCalculation());
        • A good example

          public void shouldPerformAddition() {
            Calculation calculator = newCalculation();
            int result = calculator.calculate(newCalculation(2, Operation.PLUS, 3));
    • Test behaviors, not methods

      • Behaviors can be expressed by Given, When, Then
      • Good example

        public void transferFundsShouldMoveMoneyBetweenAccounts() {
          // Given two accounts with initial balances of $150 and $20
          Account account1 = newAccountWithBalance(usd(150));
          Account account2 = newAccountWithBalance(usd(20));
          // When transferring $100 from the first to the second account
          bank.transferFunds(account1, account2, usd(100));
          // Then the new account balances should reflect the transfer
      • You can alternate when/then blocks, but for single behavior
        collapsed:: true

        public void shouldTimeOutConnections() {
          // Given two users
          User user1 = newUser();
          User user2 = newUser();
          // And an empty connection pool with a 10-minute timeout
          Pool pool = newPool(Duration.minutes(10));
          // When connecting both users to the pool
          // Then the pool should have two connections
          // When waiting for 20 minutes
          // Then the pool should have no connections
          // And each user should be disconnected
      • If you're using the word "and" in a test there's a good chance you should have two tests

    • Don't put logic in tests

      • It's very easy to make a mistake when there's logic in the test
      • Don't even have string concatenation, just repeat the value that you had in the variable
    • Write clear failure messages

      • Failure messages should have

        • What was given
        • What was expected
        • Information about the state
      • Example

        • Expected an account in state CLOSED, but got account: <{name: "my-account", state: "OPEN"}
  • DAMP > DRY

    • DAMP

      • Descriptive and Meaningful Phrases
    • DRY

      • Don't Repeat Yourself
    • a little bit of duplication is OK in tests so long as that duplication makes the test simpler and clearer

    • Shared values

      • As a whole, try to avoid them
      • They can make the code concise, but you lose context
      • You can use a helper function to replace them
      • Example
    • Shared Setup

      • It's better to have a set up and then override is than just have a setup
      • Example
  • TL;DR

    • Strive for unchanging tests
    • Test via public APIs
    • Test state, not interactions
    • Make your tests complete and concise
    • Test behaviors, not methods
    • Structure tests to emphasize behaviors
    • Name tests after the behavior being tested
    • Don't put logic in tests
    • Write clear failure messages
    • Follow DAMP over DRY when sharing code for tests