2024.02.07
システム開発でテストというと、テスターによる品質保証をイメージされるかもしれません。しかし、近年のアジャイル開発のような短いサイクルの開発プロセスにおいては、テスターのみで品質を担保することは困難であり、開発者も含めて開発工程全体で品質を意識していくことが重要になっています。
そこで今回は、開発者とテスターが一体となって品質向上を目指す手法「テスト駆動開発」の進め方をステップ毎に解説します。
- もくじ
1．テスト駆動開発（TDD）とは
テスト駆動開発（Test-Driven Development: TDD）とは、テストファーストなプログラムの開発手法です。つまり、プログラムの実装前にテストコードを書き（テストファースト）、そのテストコードに適合するように実装とリファクタリングを進めていく方法を指します。
実装したい機能のプログラムよりもテストコードを先に書くため、はじめはテストに失敗しますが、プログラムの実装と修正を短いサイクルで何度も繰り返してバグをなくし、正しく動作するコードが書けたらリファクタリングを行います。
2．ステップで分かるテスト駆動開発（TDD）の基本サイクル
テスト駆動開発は、「レッド」「グリーン」「リファクタリング」という順序で進められます。各ステップで具体的に何をするのか、以下でご紹介していきます。
【レッド】実装した機能の要件を元に失敗するテストコードを書く
テスト駆動開発では「必ず失敗するテストコードを書く」、つまり、実装したい機能を実現するコードが一切書かれていない場合でも、まずはその機能のテストコードから先に書くということが基本です。
テストツールを使っているときにテストが失敗すると赤色でエラー表示されるため、この工程はレッドと呼ばれます。このステップでは、実装したい機能の要件を適切な粒度に分けて、リストアップしておきます。
【グリーン】どんな方法でも良いのでテストが成功するコードを書く
テストコードが書けたら、機能の実装に移ります。ここで重要なポイントは、完璧なコードを書くことではなく、先に設定したテスト条件を全てクリアさせるだけの「最小限」のコードを書くということです。レッドとグリーンの工程は、リファクタリングの前に数回繰り返すこともあります。
【リファクタリング】テストが成功する状態を維持しつつ簡潔・明快なコードにする
テストを全て成功させたら、リファクタリングを行ってコードの可読性を高めます。リファクタリングは、テスト対象とするプログラムコードの規模が小さいうちに行うようにしましょう。グリーンの状態で「テストをクリアしているから今度」としてしまうと、プログラムの規模が大きくなるにつれて修正負担が増え、手がつけられなくなります。グリーンのステップを達成したら、その都度リファクタリングを行うことが理想的です。
3．テスト駆動開発（TDD）のメリット3つ
テスト駆動開発は、上記の通り「テストコードを先に書いて、そのテストコードに見合うような実装とリファクタリングを繰り返す」手法であり、一見遠回りに感じる方もいるのではないでしょうか。テスト駆動開発には3つのメリットがあります。
【1】後工程へバグを持ち越しにくい
開発者は、自分でコードをこまめに確認しながらコーディングを進めることができます。モジュールやユニットレベルでテストと実装・リファクタリングを繰り返すため、開発の初期段階で不具合を検知・修正できるようになり、後工程での手戻りの発生を減らせます。
【2】システムの要件をより深く理解できる
テストコードを書く際、必要なシステム要件を細分化してリストアップするため、網羅的で漏れのない仕様理解ができます。テストと実装を繰り返す過程で、はじめに立てたテストコードと実装内容の乖離にも気づくことができます。
【3】開発者が安心してコーディングでき、心理的負担が減る
テスト駆動開発を採用してテストコードを何度でも試せるようになると、追加のコーディングやリファクタリングを行う際にプログラムを壊してしまっていないか確認しやすくなります。プログラムの変更は不具合を生み出しやすいため、簡単にテストができるようになれば開発者も安心して作業することができます。はじめに定義したテストコードを用いて、いつでも回帰テストを行える状態にあれば、デグレードの発生も回避しやすくなるでしょう。
4．TDD運用時の注意点
導入メリットの大きいテスト駆動開発ですが、運用に当たっては考慮すべき点があります。最大の効果を得るために、以下の点に注意するようにしましょう。
TDDの導入箇所を見極め、開発時間を抑える
TDDでは実装時にテストコードを書くため、コーディングに時間がかかる可能性があります。短納期で実装しなければならない場合はレッドの工程が疎かになり、TDDがうまく機能しないこともあるでしょう。また、実装が進むにつれて機能のプログラムに加えてテストコードもメンテナンスする必要があります。
このような事態を避けるためには、TDDを導入する箇所を限定することが有効です。データベースや単純なデータの入出力に関わる部分はTDDの導入が難しい分野でもあるため、あえて導入しないということも選択肢の1つです。その場合、その後の工程できちんとテストを実施し、不具合がないことを確認する必要があります。
開発サイクルの遵守とレビューでテスト項目の漏れをなくす
テストされるべき項目が盛り込まれていないと、実際のコードは必要条件を満たしていないにもかかわらず、不具合を見落としてしまう恐れがあります。テスト項目を網羅的に挙げるための対策としては、開発サイクルを遵守し、3つのステップを繰り返し行うことと、テストコード自体のレビューがあります。
ステップを繰り返すことで抜け漏れに気づきやすくなり、経験のある開発者によるテストコードのレビューを行うことで、客観的な視点からテスト項目の網羅性をチェックできるでしょう。
おわりに
開発工程の初期段階からテストに忠実に進めていく開発手法であるTDDは、近年の短サイクルの開発プロセスでコーディングの品質を上げる手法の1つです。テストファーストでコーディング・リファクタリングを繰り返すことにより、開発段階から不具合を検知・修正することが容易になる他、開発者がシステムを理解し、安心感を持って作業を行うことに役立ちます。
開発に時間や労力を要し、網羅性の高いテスト項目を設定することは簡単ではありませんが、TDDの導入箇所を見極め、ステップに沿って適切に実施していくことが品質向上の近道です。
