はじめに
メーカーのコーポレート部門でテックリードをしているmongolyyです。
最近、単体テストの設計について考えることがあり、その参考として「単体テストの考え方/使い方」を読みました。
気づきを書いていこうと思います。
気づき
単体テストの良し悪しについて、判断する軸ができた
本書では次の観点が紹介されていました。
- 退行に対する保護
- リファクタリングへの耐性
- 迅速なフィードバック
- 保守のしやすさ
今までなんとなく良し悪しを判断していた単体テストのテストケースについて、最初の二つの観点により具体的にどう良いか、悪いか言えるようになりました。
業務でも早速この観点をもとに話せたので、役に立つ本だと感じました。
単体テストの手法について、整理できた
本書では次の手法が紹介されていました。
- 出力値ベース・テスト
- 状態ベース・テスト
- コミュニケーション・ベース・テスト
今までは、「書いたことある、見たことあるパターンだなー」となんとなくでテストを書いていましたが、言われてみるとこの三つに集約できると思いました。
また、本書の中では出力値ベーステストが、リファクタリングへの耐性を維持する、保守しやすさを維持する観点でもっとものコストが低いと書かれていて、こういったテスト、インターフェースになるといいんだなーと改めて感じました。
リファクタリングが必要な兆候と改善のアプローチを知った
「コードの複雑さ/ドメインにおける重要性」「協力者オブジェクトの数」の二軸で考えるといいと書いてありました。
これに対して、協力者オブジェクトの数を少なくする、「ドメイン・モデル/アルゴリズム」を抽出するアプローチ、コードの複雑さ/ドメインにおける重要性を少なくする「コントローラ」を抽出するアプローチの2つ手法があることが書かれていました。
個人的には次のことについて、興味深いと感じました。
- 二軸の改善を単体でするのもいいが、両方をすることで責務が明確になって認知負荷が減りそうであること
- コードの複雑性だけでなく、ドメインにおける重要性も軸となっていること
おわりに
当たり前から一歩踏み込んだことについて、著者の意見が入っていたのがよかったです。
例えば次のようなものです。
- 単体テストのテストメソッド名の話
- AAAパターンの区切りとしての空行の話
- ログ出力についてのテストの必要性の話
単体テストのアンチパターンなど、レビューのコメントで使えそうだと感じるものも多く、「一通り単体テストわかってきた、もう一歩踏み込んで理解したいぜ」という方におすすめな一冊でした。
