10.7 テスト駆動開発は失敗することがある
内容
テスト駆動開発はスキルであり、スキルが十分に習得されていないと、開発者の負荷になり、プロジェクトの進行は遅くなる。
それが原因でプロジェクトが失敗するというように判断したのなら、テスト駆動開発をやめるのが正しい。
開発者が対応できないときは、開発者に新しい学習曲線の負担をかけるべきではない。
テスト駆動開発を続けてプロジェクトを失敗させ倒産するか、テスト駆動開発をやめるかの選択に直面しているなら、テスト駆動開発をやめることはいちばん確実で正しい。
リリースの準備ができているなら、テスト駆動開発の導入に挑戦する必要はない。
テスト駆動開発の間違った会社の例
とある会社ではコードの品質、「CLEAN」なコード、優れた開発原則は導入できていたにもかかわらず、テストの運用がうまくいかなかった。
テストが冗長
コードをクリーンにするのに１日、テストをクリーンにするのに１週間かかっていた。
原因はテストコードもコードであると見直しておらず、テストの冗長性が非常に高くなっていたため。
インターフェースではなく実装に依存したテスト
インターフェイスに対してテストするのではなく、実装に対してテストをしていたため、コードのクリーンアップをしようとしたときに、テストをクリーンアップするのが困難だった。
ユニットテストの書き方が違う
テストを実行するためにOracleに接続していて、モックを使っておらず実際のDBに接続していたため時間がかかっていた。
テストの量を不要に増やした
彼らはQAの立場で「テストが多ければ良いテストだ」と考え、あまりにも多くのテストを書いていた。上記の要因を踏まえ、大量の運用できないテストを作っていた。
学び
- テスト駆動開発はスキルであり、習得が必要。習得には負荷がかかるので導入は計画的にしなければいけない。
- 負荷が高すぎたり、間違ったやり方で工数が上がりすぎては本末転倒。
学びを活かすアイディア・行動
- ユニットテストのコーディング規約づくり
失敗するとどうなるかを書く。
