単体テストの考え方/使い方を読んだ

読む以前のテストに対する私の考え

アーキテクチャはテストするためにある

クリーンアーキテクチャでは、フレームワーク独立, UI独立, データベース独立, 外部機能独立の４つの独立性と、そして、テスト可能の５つを実現するが、
独立性も結局はテストのためにあり、テストが長期的なメンテナンス性を上げるのだ。
独立してるから交換可能というのはソフトウェアアーキテクチャで解決すべき問題ではないと考える。
数年交換が必要でないかもしれないからだ。そのためだけに日頃から何かするのは違う。

重要な仕様ほどテストを行う方が良い

シンプル。致命的なバグを無くすためだ。

ロジックが複雑であればあるほど、テストを行う方が良い

仕様を満たしていることをテストコードを見れば、把握できる。
また、変更を加えるたびに、全てのパターンの動作確認をするわけにはいかない。

依存が多いほど、テストを行う価値が薄くなる

後で変更されやすくなるから。また、網羅しなくてはいけないパターンも増える。
想定されるユースケースのみを簡単にテストするべきである。

学んだこと

単体テストの定義は、少量コード、早い、隔離の３つ、但し隔離に派閥があるらしい。
結論、モックは統合と組み合わせなきゃいけないからそれなりにコスト高いよってこと。DBとか外部プロセスのモックに留めておくべき。

古典学派

• テストケースが隔離されていればOK
• TDDは内から外へ

ロンドン学派

• モック主義
• TDDは外から内へ、モックを使うので内側の開発に依存しない。先に全体の実装から入れる。

古典学派を支持する理由は？
テスト対象の依存を全てモックにすると、その依存変更時にモックも更新しなきゃいけないけど、毎回しないでしょ？ってこと。
ロンドン学派的には統合テストで検出すべきと考えている。古典学派の単体テストはロンドン学派の統合テストと近い部分がある。
古典学派は、モック使わない分、Arrangeが膨らむがプロダクションコードが悪いらしい。

良いテスト

• 開発サイクルの一部(CI): 使わなくなるのを防ぐ
• 重要な部分のみがテスト: 使わなくなるのを防ぐ
• 後退(regression) の保護: バグらない状態を続ける
• リファクタリング耐性: そのまま。リファクタしやすい
• 迅速なフィードバック: そのまま。開発しやすい

加筆中...