レガシーコードからの脱却まとめ – 10.10.2

10.10.2 優れたユニットテストのための７つの戦略

ユニットテストのための大切な７つの観点を説明している。

戦略	補足
呼び出し側の視点に立つ	呼び出し側は何を必要としているのか、何を渡す必要があるのか。
テストを使ってふるまいを表す	仕様がわかるドキュメントになるようにわかりやすく書く。テストを最新に保つことが、ドキュメントを最新に保つことになる。
新しい違いを生み出すテストだけ書く	テストは一意にする。観察可能なテストにして無駄なテストをなくす。
失敗したテストにパスするためのコードのみを書く	まず失敗するコードを書き、テストが通るコードに書き直す。このルールに則った場合に「テストが通ったら正しい」という保証になる。
テストを使って、ふるまいを作る	ハッピーパスから作るにしろ、例外からにしろ、テストから作る
コードをリファクタリングする	反復開発する場合、保守性は重要だからリファクタリングをして保守可能な状態にする
テストをリファクタリングする	実装に依存したテストではなくふるまいを表したテストを書いていなければ不要に修正する必要はない。ただし、テストもコードであるため保守可能な状態にしないとコード品質に影響する可能性がある。

テストはコードだという認識。保守可能な状態にリファクタリングする必要がある。
テストはふるまいを表すべき。実装に依存したかたちにしてしまうと不要に修正する必要の可能性が出てくるし、そうなると保守できなくなる。
テストは仕様を表す最新のドキュメント。実行することでプログラムが正しいことを表すため、仕様がわかるように書くことで、最新のドキュメントとなる。メソッドコメントのように変更し忘れがなくなる。