TDD

テスト駆動開発(Test-Driven Development: TDD)とは、テストファーストなプログラムの開発手法です。
つまり、プログラムの実装前にテストコードを書き(テストファースト)、そのテストコードに適合するように実装とリファクタリングを進めていく方法を指します。

実装したい機能のプログラムよりもテストコードを先に書くため、はじめはテストに失敗しますが、プログラムの実装と修正を短いサイクルで何度も繰り返してバグをなくし、正しく動作するコードが書けたらリファクタリングを行います。
システム開発でテストというと、テスターによる品質保証をイメージされるかもしれません。しかし、近年のアジャイル開発のような短いサイクルの開発プロセスにおいては、テスターのみで品質を担保することは困難であり、開発者も含めて開発工程全体で品質を意識していくことが重要になっています。

テスト駆動開発は、「レッド」「グリーン」「リファクタリング」という順序で進められます。各ステップで具体的に何をするのか、以下でご紹介していきます。

【レッド】実装した機能の要件を元に失敗するテストコードを書く
テスト駆動開発では「必ず失敗するテストコードを書く」、つまり、実装したい機能を実現するコードが一切書かれていない場合でも、まずはその機能のテストコードから先に書くということが基本です。
テストツールを使っているときにテストが失敗すると赤色でエラー表示されるため、この工程はレッドと呼ばれます。このステップでは、実装したい機能の要件を適切な粒度に分けて、リストアップしておきます。

【グリーン】どんな方法でも良いのでテストが成功するコードを書く
テストコードが書けたら、機能の実装に移ります。ここで重要なポイントは、完璧なコードを書くことではなく、先に設定したテスト条件を全てクリアさせるだけの「最小限」のコードを書くということです。レッドとグリーンの工程は、リファクタリングの前に数回繰り返すこともあります。

【リファクタリング】テストが成功する状態を維持しつつ簡潔・明快なコードにする
テストを全て成功させたら、リファクタリングを行ってコードの可読性を高めます。リファクタリングは、テスト対象とするプログラムコードの規模が小さいうちに行うようにしましょう。グリーンの状態で「テストをクリアしているから今度」としてしまうと、プログラムの規模が大きくなるにつれて修正負担が増え、手がつけられなくなります。グリーンのステップを達成したら、その都度リファクタリングを行うことが理想的です。

テスト駆動開発(TDD)のメリット3つ
テスト駆動開発は、上記の通り「テストコードを先に書いて、そのテストコードに見合うような実装とリファクタリングを繰り返す」手法であり、一見遠回りに感じる方もいるのではないでしょうか。テスト駆動開発には3つのメリットがあります。

【1】後工程へバグを持ち越しにくい
開発者は、自分でコードをこまめに確認しながらコーディングを進めることができます。モジュールやユニットレベルでテストと実装・リファクタリングを繰り返すため、開発の初期段階で不具合を検知・修正できるようになり、後工程での手戻りの発生を減らせます。

【2】システムの要件をより深く理解できる
テストコードを書く際、必要なシステム要件を細分化してリストアップするため、網羅的で漏れのない仕様理解ができます。テストと実装を繰り返す過程で、はじめに立てたテストコードと実装内容の乖離にも気づくことができます。

【3】開発者が安心してコーディングでき、心理的負担が減る
テスト駆動開発を採用してテストコードを何度でも試せるようになると、追加のコーディングやリファクタリングを行う際にプログラムを壊してしまっていないか確認しやすくなります。プログラムの変更は不具合を生み出しやすいため、簡単にテストができるようになれば開発者も安心して作業することができます。はじめに定義したテストコードを用いて、いつでも回帰テストを行える状態にあれば、デグレードの発生も回避しやすくなるでしょう。

TDD運用時の注意点
TDDの導入箇所を見極め、開発時間を抑える
TDDでは実装時にテストコードを書くため、コーディングに時間がかかる可能性があります。短納期で実装しなければならない場合はレッドの工程が疎かになり、TDDがうまく機能しないこともあるで、実装が進むにつれて機能のプログラムに加えてテストコードもメンテナンスする必要があります。

このような事態を避けるためには、TDDを導入する箇所を限定することが有効です。
データベースや単純なデータの入出力に関わる部分はTDDの導入が難しい分野でもあるため、あえて導入しないということも選択肢の1つで、その場合、その後の工程できちんとテストを実施し、不具合がないことを確認する必要があります。

開発サイクルの遵守とレビューでテスト項目の漏れをなくす。
テストされるべき項目が盛り込まれていないと、実際のコードは必要条件を満たしていないにもかかわらず、不具合を見落としてしまう恐れがあり、テスト項目を網羅的に挙げるための対策としては、開発サイクルを遵守し、3つのステップを繰り返し行うことと、テストコード自体のレビューがあります。

ステップを繰り返すことで抜け漏れに気づきやすくなり、経験のある開発者によるテストコードのレビューを行うことで、客観的な視点からテスト項目の網羅性をチェックできるでしょう。

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)

用語

前の記事

Code Smell
用語

次の記事

A1QA