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