スローテストとは？
自動テストによるフィードバック（グリーン or レッド）が返ってくるのが遅い状態。この状態に陥ると、開発効率が追う幅に低下して、品質も低下に向かっていく。
ある者は毎回テストのフィードバックを待っている間にタバコに席を立ち、コーヒーを入れ、まだ終わってなければ、RSSを見始め、Twitterをして時間をつぶす。
ある者はテストを走らせることなく実装に走り出す。ランチに行く前にコミットして、返ってきた頃には午前中やった部分のどこがテストで落ちたのか、探すところから開発がスタート。テストが落ちたのをなおし終わった時には、もう夕方。
そんなことをやっている場合じゃない。今すぐテスト戦略と戦術を見直すべきだ!!
まだ、テストのフィードバックがランチに行って、帰ってくる間に終わっているのであれば、改善するのは夢物語ではない。一晩がかりで自動テストを走らせるような状態だと、自動テストをするために専用の大規模な環境が必要になってくるだろう。
テストケースを見直す
- 本当に必要なテストだけをしているだろうか？
- 無駄なテストを永遠と何回も実施していないだろうか？
必要なテストだけに絞り込ませよう。
確率系のテストケースは適切か？
- 50%の確率で白か黒になるというテストを数千回実施していたりしていないだろうか？
- それは本当に重要なことなのだろうか？
- 他のテストケースで代替えできないだろうか？白か黒がでればだめであろうか？
- 10回実施して2回以上白と黒がでれば、だめだろうか？
テストケースに折り合いをつけよう。
外部APIへの接続
- 本当にAPIに接続する必要あるだろうか？
- モックやスタブは作成できないだろうか？
- 本番APIの代わりに開発用APIをビルドサーバに持てないだろうか？
見当してみよう。やってみよう。試してみよう。
データベースへの接続
- DBと切り離したテストができないか？
- モックやスタブができないか？
- インメモリDBで対処できないか？
- 一つのFixtureですべてのテストを実施できないか？
- トランザクションとロールバックを活用できないか？
見当してみよう。やってみよう。試してみよう。
分散ビルド
これは最終手段だと考えている。テストケースを複数台にわけて、分散ビルドさせる。1台でやっていることを2台で半分ずつやれば半分の約時間で終わるはずである。
いらないサーバは余ってないだろうか？探してみよう。つくってみよう。
まとめ
テストは開発者の健康状態を保つ。テストが足を引っ張ってしまう状況は、地獄への道を進み始めている。自動テストを味方につけ、一緒に戦っていける環境をつくりあげよう。
 |
Gerard Meszaros￥ 5,682 (null OFF)
|
