かすてらすねお。

見聞録的ななにか。

『実践テスト駆動開発』(2012)第1章「テスト駆動開発のポイントとは?」を読んだ

サマリー

問題提起(pp.3-4)

  • ソフトウェア開発は本質的に学習プロセスである
    • ほとんどすべてのソフトウェアプロジェクトは、誰も経験したことのないことに挑戦している
    • 開発者は使用技術を完全に理解していないことが多い
  • 学習プロセスにおいてフィードバックは重要なツールである
    • フィードバックループとは、秒単位(ペアプロ)から月単位(リリース)まで、異なる時間スケールで入れ子状に存在するループ
      • 内側(技術的詳細)と外側(組織的側面)がある
    • 各ループのサイクル(アクション・観察・改善)は学習を具体化する仕組みである
      • アクション:デプロイやテストなどの実施
      • 観察:仮定と現実の称号、進捗測定、エラー検出
      • 改善:計画の調性、修正

TDD のサイクル(pp.5-10)

  • 予期せぬ変更に対応するためには2つの技術的基盤が必要
    1. 継続的なテスト(リグレッションエラーを捕捉するため)
    2. シンプルなコード(理解と修正を容易にするため)
  • これらの実践的要件を満たすために TDD を導入する
    • TDD の基本サイクルは「失敗するテストを書く→コードを書いてテストを通す→リファクタリングする」の繰り返しである
  • ユニットテストではなく受け入れテストから開発を始めるべき
    • コードには実際に使われなかったり統合できなかったりするリスクがある
    • まず失敗する受け入れテストを書き、この大きな文脈の中でユニットテストを使用する
  • 受け入れテストは可能な限りエンドツーエンドで行うべき
    • ユーザーインターフェイスからの操作だけでなく、ビルドからデプロイまで全プロセスを含むべき
    • TDD を単なるコードレベルの実践から、組織の運用プロセス全体を考慮した包括的アプローチへと拡張する

テストと品質(pp.10-12)

  • テストには3つのレベルがある
    1. 受け入れテスト:システム全体が機能するかを確認する
    2. インテグレーションテスト:外部のコードとの統合を確認する
    3. ユニットテスト:オブジェクトの機能を確認する
  • テストは品質に関係する
    • テストを「実行すること」と「書くこと」は異なる品質側面に寄与する
    • 各テストレベルは、外部品質と内部品質の両方に何らかの形で貢献する
    • これらのテストを組み合わせることで、総合的な品質保証を可能にする

Follow me on X: @suneo3476Web