かすてらすねお。

見聞録的ななにか。

『Clean Code』(2017)第9章「単体テスト」を読んだ

読書

第9章 単体テスト

前書きは良くないテストの例。

サマリー

  • (pp.174-175)

    • TDD 三原則 に従うと製品コードの量に匹敵する大量のテストコードを書かなくてはならない

  • (pp.175-176)

    • 汚いテストを許容すると、製品コードの安全な変更を保証するためのテストスイートの保守コストが大きくなる
    • テストをきれいに保つことは製品コードの品質を保つことにつながる

  • (pp.177-180)

    • 洗練されたテストコードは詳細がなく読みやすい
    • テストコードをリファクタリングして、読み書きを楽にするテストAPI（ドメイン特化テスト言語）を作ろう
    • 『リーダブルコード』でテストコードを改善する例が理解しやすかったのを思い出した

  • (pp.180-183)

    • API テストの二重規範とは、テストコードと本番コードに求められるエンジニアリング基準が異なること
      • 共通の基準：読みやすさ（クリーンさ）
      • 異なる基準：効率性（メモリ使用量やCPU使用量など）

  • (pp.183-185)

    • 1つのテストのアサート文の数はなるべく少なくするべき
    • 1つのテストでは1つの概念を扱うべき

  • (p.186)

    • クリーンテストは5つの規則がある（割愛）

考察・要約

  • 単体テストの作成は、インターフェイス設計と使用シナリオを具体的に表現する方法

  • TDD はテストを通じて設計を洗練する発見的な設計手法

    • TDD ではテストコードと製品コードが密接に結びついている
    • TDD のプロセスはコードの要件を明確にし、その要件を満たすように段階的に設計が発展する

  • 単体テストは「使われ方」を定義し、TDD でその「使われ方」を満たす設計を発見していく

    1. まず失敗するテストを書く（＝使われ方を定義）
    2. それを通すための最小限の実装を行う（＝その使われ方を実現）
    3. このサイクルを繰り返して設計を発展させる（設計が変更されることもある）

Follow me on X: @suneo3476Web