「単体テストの考え方/使い方」を読んで
この本の概要
ソフトウェアの品質改善とプロジェクトの成長のための単体テストの戦略を解説しています。 良い単体テストとはなにかから、リファクタリング戦略・モック戦略、単体テストと結合テストの違いまでテストの考え方について幅広く扱っています。
https://www.amazon.co.jp/dp/4839981728
おすすめしたい人
- テストコードを書いたことがあり、テストコードでどこまで書くか・どのプロダクションコードに対してどのようなテストコードでテストすべきか方針に悩んでいる人。
感想
単体テストの話だけでなく、プロダクションコードの設計についても触れられていて、包括的にコードの品質改善のことを考えられてよかったです。 モックや単体テスト・結合テストの違いなど、普段から使っているけれどもいざ自分の考えをまとめようとするととうまく整理できていないところについて 学術的な背景にも触れて書かれていました。自分の経験を整理する一助となりました。
特に学びになったところ
単体テスト・結合テストの違い
- 単体テストは持続可能なソフトウェア開発をするためある。
- 良い単体テストがあると、コードを追加・変更してもソフトウェアが退行していない自信になり、機能追加やリファクタリングしやすくなる。
- 単体テストには3つの特徴がある。
「単体」と呼ばれる少量のコードを検証する。 実行時間が短い。 隔離された状態で実行される。
- 単体テストには古典派とロンドン学派の2つの流派がある。
- 古典派は1つの振る舞いに対してテストし、ロンドン学派は1つのクラスに対してテストする。
- 古典派はテストケース間で共有される依存(DBやファイルシステム)のみモックし、ロンドン学派は不変依存(値オブジェクトや列挙型などその値のみで識別されるもの)を除く全ての依存に対してモックする。
- 著者は古典派を好んでおり、ロンドン学派だと実装の詳細に対するテストになりやすく賛同できない。
モックの使い方
- 単体テストではモックを使わない。管理下にあるコードをモックすると整合性が取れていなくてもテストが通ってしまう場合がありテストの価値が下がる。
- スピードが遅くなることが懸念されるが、整合性はテストで担保されるべきでありチェックすべきとこる。
- DBのテストは書き込みは必ずテストする。読み込みは重要な部分だけテストする。
- 結合テステストでは管理外のコードも利用するので、管理外のコードに対してのみモックを使う。
モックを使っていいのはシステム間コミュニケーションの場合で、かつそのコミュニケーションが外部から観察できる場合である。
リファクタリングが必要なコードの識別
- コードの種類を4つに分類している
| 協力オブジェクトの数が少ない | 協力オブジェクトの数が多い | |
|---|---|---|
| コードの複雑さ・ドメインにおける重要性が低い | 取るにとらないコード | コントローラ |
| コードの複雑さ・ドメインにおける重要性が高い | ドメインモデル・アルゴリズム | 過度に複雑なコード |
