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