単体テストの考え方/使い方 プロジェクトの持続可能な成長を実現するための戦略
著 : Vladimir Khorikov
訳 : 須田智之
https://m.media-amazon.com/images/P/B0BLTG8Z9K.01._SCLZZZZZZZ_SX500_.jpg
Amazon : https://amzn.to/3JjOxbl
単体テストのベストプラクティスとアンチパターンが書かれた書籍
作成した単体テストが最大限の価値をもたらすようになるまでに読者を導く
感想 nobuoka.icon
全体を通してそこそこいいことが書かれてはいる
バイブルと呼べるようなめちゃいい本かと言われるとそこまででもない
単体テストや統合テストの定義が独自な感じだったり
「ドメイン層からプロセス外への依存を持たせることは (インターフェイスを切ってテスト可能性を上げたとしても) 常にやるべきではない」 みたいな主張でちょっと過激
モナドを活用するとかそういう話まであると良かったかもしれない？
自分にとっては、本書で得られた有益な考え方は、テストメソッドの命名についてと、関数型アーキテクチャの話ぐらい
ソフトウェアテストについて経験が浅い人は読むと得られるものは多いと思う
が、本書だけではなくて他の文献にもあたった方が良い
1 部 単体 (unit) テストとは
単体テストの概要
1 章 なぜ、単体 (unit) テストを行うのか？
ほとんどのプロジェクトで単体テストは当然のことと思われるようになってきた
議論は、「単体テストを書くべきか」 から 「良い単体テストとは？」 に移ってきている
単体テストを書く目的は、プロジェクトを持続可能なものにすること
単体テストがないと、ソフトウェア・エントロピーの増大により成長とともに開発スピードが急激に落ちる
一方で、単体テストの保守コストが大きいと価値がなくなってしまうので、質の良いテストケースのみをテストスイートに入れる必要
網羅率 (coverage)
優れたテストスイートの特徴
テストすることが開発サイクルに組み込まれている : 理想的には、コードが変更されるたびにテストされること
コードベースの重要な部分のみがテスト対象となっている
最小限の保守コストで最大限の価値を生み出せる
テストスイートの価値を高めるには？
価値あるテストケースを認識できるようになる
価値あるテストケースを作成できるようになる
2 章 単体テストとは何か？
単体テスト
古典学派の聖典は 『テスト駆動開発 (Beck)』
ロンドン学派の聖典は 『実践テスト駆動開発』
3 章 単体テストの構造的解析
AAA パターン
テストフィクスチャー
テストメソッドの命名
事前条件や返り値をメソッド名に入れてもさほど役に立たない
振る舞いをテストすべきなので、テスト対象メソッドの名前をテストメソッドの名前に入れるべきではない
ドメインエキスパートな非開発者にも伝わるような命名をすべし
2 部 単体テストとその価値
良い単体テストを構成するものは何か、どうすれば既存のテストをより価値あるものにできるか
4 章 良い単体テストを構成する 4 本の柱
4 本の柱
退行 (regression) に対する保護
偽陰性 (false negative) を抑えること
リファクタリングへの耐性
偽陽性 (false positive) を抑えること
迅速なフィードバック
保守のしやすさ
最初の 3 つはすべては同時には成り立たせられない
ソフトウェアテストにおける良く知られた概念
テストピラミッド
ブラックボックステストとホワイトボックステスト
5 章 モックの利用とテストの壊れやすさ
テストダブル
モック、スタブ
プロダクションコードの分類
公開された API か否か？
観察可能な振る舞いか、実装詳細か？
ヘキサゴナルアーキテクチャ
6 章 単体テストの 3 つの手法
単体テストの手法
関数型プログラミング、関数型アーキテクチャ
隠れた入力や出力 : 副作用、例外、内部や外部の状態の参照
7 章 単体テストの価値を高めるリファクタリング
次の 2 軸でプロダクションコードを分類
コードの複雑さ・ドメインにおける重要性
協力者オブジェクトの数
どちらも大きい場合は過度に複雑なコードなので、どちらかの軸を小さくしていく
過度に複雑なコードを分割するのに質素なオブジェクト (Humble Object) と呼ばれる設計パターンが使える
確認後実行パターン (CanExecute/Execute パターン)
ドメインイベントの利用
3 部 統合 (integration) テスト
8 章 なぜ、統合 (integration) テストを行うのか
統合テストについて
プロセス外依存の分類
管理下にあるもの : テスト対象アプリケーションの実装詳細とみなせるもの
テスト対象アプリケーション外部からは、テスト対象アプリケーションとその依存とのやりとりを見ることができない
管理下にない依存
9 章 モックのベスト・プラクティス
管理下にあるものは実装詳細なのでモックで置き換える必要はないが、管理下にない依存との通信は観察可能な振る舞いの一部なので、モックに置き換えてテストする
管理下にない依存との通信内容のリグレッションを回避する
E2E テスト
実装クラスが 1 つしかないのにインターフェイスを切るのは無意味
YAGNI に反する
(複数の実装クラスがありえないなら) プロセス外依存をモックにする場合にのみインターフェイスを切ると良い
層が多いと関心事が分散して理解が難しくなるし、コントローラとドメインモデルの境界があいまいになってテストもしづらい
ログ出力をテストすべきか？
サポート・ログと診断ログ
構造化ログ
静的メソッドからオブジェクトを取得
『Dependency Injection Principles, Practices, Patterns』 にて、このような依存の取得のことを環境コンテキスト (ambient context) というアンチ・パターンとして紹介
10 章 データベースに対するテスト
まずはスキーマをソースコード管理システム (Git など) で管理すること
変更履歴を追えるようにする
Single Source of Truth とする
スキーマに参照データ (reference data) を含める
いわゆるマスターデータ
変更は状態ベースではなく移行ベースで扱う
Flyway や Liquibase など
移行の手順が明確になることが良い点
データ・モーション (data motion) は多くのプロジェクトで重要
データベース・トランザクションの話
単位作業 (Unit of Work) パターン : ビジネス操作の完了時に、データの変更を 1 単位にまとめてデータベースに反映する
メモリ内データベース (インメモリデータベース / in-memory database) はお勧めしない
実際のデータベースとの差異がありうるため、偽陽性や偽陰性が起こりうる
4 部 単体テストのアンチ・パターン
11 章 単体テストのアンチ・パターン
#書籍 #文献