不具合の検出が後工程になればなるほど改修対応のコストがかかるというのが一般的な認識でしょう。そこで、できるだけ前工程で不具合をつぶして対応コストを下げ、品質を上げるためにテスト駆動開発(Test-Driven Development：TDD)の導入をしたいと考える方もおられると思います。はたしてテスト駆動開発は品質の救世主となりえるのでしょうか。メリットとデメリットと合わせてテスト駆動開発についてご紹介します。
テスト駆動開発（TDD・テストドリブン）とは
テスト駆動開発（Test-Drive Development：TDD テストドリブンとも言う）とは、テストファーストな開発手法です。あくまでも開発手法であり、品質を保証するためのテストではない点に注意が必要です。テスト駆動開発は以下の３つのステップを繰り返していきます。
【テスト駆動開発 ３つのステップ】
- Red：実装すべき機能要件を元にテストコードを書く
- Green：テストコードがPass（成功）するプロダクトコードを実装する
- Refactor：テストが成功する状態を維持しながら重複を取り除く(コードを美しくする
おそらく、この部分だけを切り取って見ると誤解を生じるのではないかと思いますので、少し補足します。
- Red：実装すべき機能要件を元にテストコードを書く
このステップで重要なポイントはテストコードを書く前に、何を実現(実装)すべきなのかを明確にしてテストパターンを書き出しておくという点です。「テストパターン＝実装するものリスト」と考えるとよいでしょう。もう一つ重要なポイントを挙げるとすると、前述の通り「品質を保証するためのテストではない」という点です。つまり「C0／C1／C2 カバレッジの網羅率を○○%にする」といった目的で行うものではないということです。※結果的に網羅することはあり得ます
- Green：テストコードがPass（成功）するプロダクトコードを実装する
このステップではテストコードがPassとなる「最低限」のプロダクトコードを実装しますが、いきなりすべてのテストがPassするものを実装する必要はありません。「実装するものリスト」に対して一つずつ実装を積み上げていくようなイメージです。
- Refactor：テストが成功する状態を維持しながら重複を取り除く(コードを美しくする)
テストコードをPassするように実装を行うと、いわゆるコードが散らかった状態になります。このステップではそういったコードを見直していきます。熟練の方であれば初めから美しいコードを書くことも可能だと思います。しかし、このステップがある前提で「美しいコードを書かねばならない」という心理的プレッシャーからは一旦解放されましょう。
ただし、テストがPassした状態=動く状態 であるためこのステップを省かない(後に積み残さない)ように注意すべきです。リリースされ運用され続ければ当然仕様の追加・変更が発生し、コードが大きくなっていきます。大きくなればなるほど後の修正が大変になり、結局やらなくなるという悪循環を作らないようにしましょう。
バルテスのサービスがわかる
テストアウトソーシング基本ガイドブック
テスト駆動開発のメリット・デメリット
どのようなものでも必ずメリットとデメリットがあります。これから導入を考えている方はメリット・デメリットを合わせて検討する必要があります。
まずは代表的なメリットからご紹介します。
【メリット】
- メリット① 実装する時点で不具合の検出が可能となり、後工程に不具合を持ち越しにくい
テストと実装を平行に行っていくため、早期の不具合検出と解決が可能になります。また、「最低限の実装を行う」「リファクタリングによって実装コードが整理される」という点から簡潔な実装になることが期待できます。よって不具合が混入しにくくなります。このため、後工程に不具合を持ち越しにくいというメリットに繋がります。
- メリット② 実装担当者の仕様への理解が深まる
「実装すべき機能要件を元にテストコードを書く」ためには要件を理解・分解する作業が必然的に発生します。この作業により担当者の要件への理解が深まり、実装途中での認識齟齬などにも気づく可能性が高くなります。
- メリット③ コーディング時の心理的不安が軽減される
動作を確認するためのテストコードが用意された状況となります。よってプロダクトコードに手を入れた際に「プログラムを壊してしまう」「デグレードを発生させてしまう」という心理的負担の軽減が期待できます。「実装するものリスト」が明確になっているため、進捗を測りやすいという管理面でのメリットも期待できます。他にも細かいメリットはありますが、もちろん良い事ばかりではありませんのでデメリットにも目を向けてみましょう。
デメリットは以下のようなものがあります。
【デメリット】
- デメリット① 工数がかかる
本来のプロダクトコードの実装とは別にテストコードの実装を行う必要があるため、当然ながらその分の工数がかかります。 プロダクトコード実装の生産性が下がる、と言い換えた方が良いかもしれません。 また、仕様変更や追加開発の際にもテストコードの修正や追加が必要になります。
- デメリット② 慣れるまで一定のストレスがかかる
新しい仕事の進め方を取り入れる場合、慣れて定着するまでは担当者に一定のストレスがかかります。導入を推進する管理者の方も同様でしょう。開発の現場に限った話ではなく、新しい仕事の進め方を取り入れる場合には同様の課題にあたることがほとんどだと思います。みなさんにも容易にご想像いただけると思います。
- デメリット③ テストコードのレビューが必要になる
工数がかかるという点ではデメリット①に通じますが、正しいテストが実装されているかという観点でのレビューが必要になります。 テストコードを実装したものの、実は有効なテストではなかった、という事態になるとすべてが無駄になってしまいます。「テストしたつもりになってしまう」、というのが一番避けるべきかもしれませんね。
イテレーション内のフィーチャー検証や、リリース前のプロダクト品質テストをサポート
アジャイル開発テスト支援サービス
テスト駆動開発で救えるもの・救えないもの
テスト駆動開発の手法とメリット・デメリットについてご紹介してきました。この手法によって救えるもの(カバーできる品質)・救われないもの(カバーできない品質)についても触れておきます。
- 救えるもの
すでにお伝えしていますが、開発のための手法であり品質を保証するための手法ではありません。またテストコードも単体テストのスコープであるため、いわゆる「単体テスト工程で検出するべき」と分析されるような不具合の検出が可能であることは予想できると思います。そもそも単体テストのカバレッジ○%を達成するといった目的で行うものではないという点にも注意が必要です。そう考えるとプロダクトコードの品質を高めることによりデグレードを防ぐことができる効果がある、といった方が良いかもしれません。
- 救えないもの
前述の通り、単体テストがスコープであるため、それ以降の結合テストやシステムテストでのみ検出できるような不具合は当然ながら検出できません。 テストコードを書いたからといってテストが不要になるわけではありませんので、適用範囲を見定めて導入することが重要です。
まとめ
「テスト駆動開発は品質の救世主となりえるか」と題して、TDDについて紹介しました。
【総括】
- テスト駆動開発は開発手法であってテストではない
- テストコードを書いたからといってテストが不要とはならない
結局のところ、TDDだけでは品質の救世主にはなりえないと言えますが、
- 開発者の仕様理解度を高め認識の齟齬を防ぐ
- コードの品質を高めてデグレードの発生を防ぐ
という点では品質向上への一助となるのではないでしょうか。テスト駆動開発を活用しながら、様々な取組みにより、システム開発の品質向上を目指していきましょう。
当サイトでは、テスト技法を学びたい方、アジャイル開発やマイグレーションのテスト手法について知りたい方、テストアウトソーシングサービスに興味のある方へ、ダウンロード資料を多数ご用意しております。ぜひダウンロードいただき、資料をご活用ください。
