Testing and design quality

Did the change break anything?

• You move the fine calculation out of Loan into its own class. The program still starts, but is every result still the same?
• Clicking around proves very little. A good test suite answers in one second, and this lesson shows how to write one.

Tests pin behaviour

• Refactoring 重构 changes structure without changing behaviour. It is only safe when the behaviour is pinned down.
• Unit tests 单元测试 are those pins: each one checks one promise the code makes.

Arrange, act, assert

• One test, one behaviour: arrange 准备 the objects, act 执行 with one call, assert 断言 the outcome the caller can see.

def test_renew_ok():
    loan = Loan(20)       # arrange
    out = renew(loan, 7)  # act
    assert out == 27      # assert

Behaviours, not methods

• Name tests after behaviours: "renew past the limit raises" is a behaviour; test_days is just a method name.
• A behaviour test survives renames and fails exactly when a promise changes. Assert what callers see, not private fields.

Test the boundary

• renew allows up to 30 days, because the check is > 30. Test three points: inside (20 + 7 = 27), exactly on the limit (20 + 10 = 30, allowed) and past it (20 + 11 raises, loan unchanged).
• The boundary test catches the classic slip of writing >= for >.

The coverage grid

• List behaviours down the side and tests across the top. Each filled cell is a behaviour a test pins.
• An empty row is the next test to write. Coverage follows the list of promises, not the lines of code.

Refactor under green

• Move fines into a FineCalculator class (the single responsibility principle 单一职责原则: one reason to change), and the renew tests still pass untouched.
• Coupling 耦合 (how much classes depend on each other) went down; cohesion 内聚 (one purpose per class) went up. That is the direction of every good change.

Worked example: one bug, one red test

Three common slips

Recap