ユニットテストを書こう
- 自動テストなので一度書いておけば「めんどくさいからテスト省略」→省略したところに不具合あった、のコンボを阻止できる。
- 関数を大きくしすぎるとテストしにくくなるので、
適度なサイズに保つ働きがある。
- クラスを大きくしすぎるとモックが使いにくくなるので、
適度なサイズに保つ働きがある。
- 新機能追加のときにエンバグする可能性が減る。
- 新機能追加のときに、最初にテストの方に手を入れれば、
コードのどこを直せばいいかすぐわかる。
- デバッグのとき、バグが再現するようなテストを書いておけば、
直ったと自信を持って言える。
- テストしやすくしようとすると、自然に疎結合になる
(cf. 疎結合: ソフトウェアの依存関係を緩和してアプリケーションの柔軟性を高める)。
- クラスや関数について、
通常の使い方とテストでの使い方の2種類を最初から用意するわけなので、
以降の拡張で3種類、4種類と使い方が増えたとしても
対応しやすいコードになっているはず。
- できあがったプログラムは、
適度なサイズに分割された関数・クラスの集合になっていて、
必要に応じて様々に組み合わせることができる状態になっており、
将来の拡張がしやすい。
というようなことを説いて新入社員を洗脳する計画である。
今日「リファクタリング」
という本買ったし、
前に「テスト駆動開発入門」
も読んだんだけど、
デザインパターンとユニットテストを網羅というか、
関連づけて説明した本ってないかなあ。
こういう時はこのパターンを使い、そのときのテストはこう書くべし、みたいな。
つか、デザインパターンに挙げられているような設計はテストしやすいのだ、
というのが素早く実感できればいいのだけど。
テストファーストというとユニットテストのことだけど、
自動化できない機能テスト、結合テストについても、
予め(実装以前・実装と並行して)
テスト項目を作っておいた方がいいのかなとか思ったり。
自動化できないということは
「めんどくさいからテスト省略」→省略したところに不具合あった、
のコンボを起こしやすいんだよなあ。人間の心理的に考えて。