テスト駆動開発の実践①

「データベースからデータを取得して、帳票に出力するプログラムを作成するという」プロジェクトでJUnitを使用したテスト駆動開発を取り入れてみようと思い、いろいろ画策してみた結果、ある程度導入できた(現在進行中)のでここにまとめます。

今回やろうと思ったテスト駆動開発の導入ポイントは以下の2点になります。

ポイント1.JUnitによるテストの自動化

ポイント2.JUnitによるテストケース作成→PG→リファクタリングの流れで開発を行い詳細設計は事前に行わない。

※顧客要件(どのようなデータを取得し、どのような帳票を出力しなければならないか)は確定済の前提

【結果】
○ポイント1
・JUnitのみで検証可能な機能、手動による検証が必要な機能に切り分けてテストを行うことになりました。
DBからデータを取得する機能、取得したデータを編集して配列に変換する機能、配列データを元にCSVファイルを作成する機能(CSV形式にする以外の編集処理はなし)をJUnitで保証し、これらの機能を呼び出すmainソースについてはコンパイル後実行環境でいくつかのパターンテストを実施します。

(テスト結果のエビデンス)
・JUnitのjavadoc
・テストソース
・JUnitテスト結果のハードコピー
・Excelで作成した基本的なテストパターン表(結果記入済)
・手動テストの場合は、ログ、ハードコピー、テストなど

○ポイント2
テスト「駆動」の部分については、半分くらい導入できました。
状況としては、以下のような流れでの開発を行う予定です。

まず基本パターンのみテストプログラムを作成し開発を実施する。
→一旦開発完了したら詳細なテストパターンに基づいたテストプログラムを作成、実行する。
→バグがあったら修正する。(ケース間違いの場合はケースを修正する)

なんでこんな中途半端なことをすることになったかというと、
「バグ発生率を取得する為」でした。
本来は「テストプログラムを作成→テスト実行しながらPG」という流れの為、PGが完了した時点でバグは0になります。
その為、バグ発生率は常に0なんですが、それがまずいと…
受け入れ元には、開発後のテストでどれくらいバグが発生したかを報告する必要がありそれが全て0になってしまうと確実に突っ込みをくらってしまいます。
確かに、PG完→テストであればなにかしらバグは出ますからね…

リーダーといろいろ検討しましたが、ポイント1,2を概ね受け入れてくれただけでもかなり調整が必要なようなので、今回はとりえあえず十分かと思いこのような状況となりました。


続く
(参考にした書籍)