導入
前回紹介したテスト駆動開発の手順は自動化できるテスト の範囲です。狭い意味ではここまでがテスト駆動開発です。今回紹介する総合的なテストは自動化できない（しにくい）テスト の範囲になります。
テスト駆動開発を広い意味でとらえ、今回紹介する総合的なテストもテスト駆動開発の一部として紹介します。これは私の独自の解釈です 。アプリケーション開発が中盤から終盤に入ってくると、ユニットごとに分離して動作テストするだけでは確認できないことがあるからです。総合的なテストとは「アプリケーションの総合的な動作」「 UIの操作感」といった、コードがアプリケーションとして目的を果たすかどうかのテストです。総合的なテスト結果から明らかになる不具合、問題、バグを各ユニットテストに反映し、更新されたユニットテストに合格したら、また総合的なテストを行います。アプリケーションの開発は、このような上昇スパイラルをたどります。
それでは、前回開発を開始した健康管理アプリケーションを、テスト駆動開発で完成させましょう。
展開
前回は、健康管理アプリケーションに必要となるクラスを考案し、そのユニットテストを行いました。具体的には、PersonalDataクラスを作成して体重、身長を与えると、BMIや肥満度を正しく算出するようにしました。もちろん、テスト駆動ですからPersonalDataクラスをテストするメソッドから先に記述しました。そして、PersonalDataクラスが確実に動作することが確認できました。
今回は、DEBUG_MODE 定数をfalseにし、このスケッチをアプリケーションとして実行して、目的の動作をするかを確認して行きます。
HealthApp.pde の冒頭、デバッグモードのフラグを降ろしたところ //final boolean DEBUG_MODE = true;
final boolean DEBUG_MODE = false ; その際、与えるデータや操作のパターンには異常な場合も含んでください。あり得ない場合の出力や反応を確かめるのです。ユーザは常にアプリケーション作成者が意図したように操作してくれるとは限りません。作成者からすれば、ユーザは目的外のとんでもない操作をするものだと心得ておいたほうが良いでしょう。
ここでは、アプリケーションの動作やユーザインタフェイス（以下UIと略す）などを次のように規定します。
アプリケーションの動作概要
起動時、UIにはデフォルトの体重、身長を表示し、それに基づくBMIと肥満度を表示する。
UIにある増減ボタンをマウス操作して体重と身長を入力する。体重は1kg、身長は1cmずつ増減する。
体重や身長が変化したら、BMIと肥満度が自動的に更新表示される。
体重や身長が規定の範囲を超えた場合はデフォルトの値に戻す。
UIにあるスティックマンの顔をクリックすると、男女が切り替わる。男性は青、女性は赤で表す。
UI
テスト項目
このアプリケーション全体の動作やUIのテスト項目として、以下のものを定めます。
体重や身長の増減ボタンを操作するとそれぞれの値が望む変化を起こすか
体重や身長の操作の結果、規定の範囲を超えたらデフォルトの値に戻るか
BMIや肥満度の値は正しい値が表示されるか
ディスプレイウインドウ内のあらゆるところをクリックして、目的外の動作をしないか
これらのテスト項目は、自動的なチェックが困難です。地道にマウスやキーボードの操作をして問題を洗い出します。上のテスト項目をチェックリストとして、バージョンアップごとにチェックをすれば、公開するアプリケーションについて「テスト済み」という保証ができます。
アプリの完成とバージョンアップ
使用するクラスの機能追加とユニットテスト
健康管理アプリケーションの全体像を考えると、性別、体重、身長をUIから変更する必要があることがわかりました。そこで、PersonalDataクラスのコードに変更を加え、目的に沿うようにします。前回までは、個人情報のセットはPersonalDataクラスのコンストラクタからのみ行っていましたが、性別、体重、身長についてセットメソッドを追加します。
具体的にはPersonalDataクラスに、メソッドsetSex, setYourWeight, setYourHeightというセットメソッドを追加します。
まずテストコードを書き、それに合格するようコードを変更し、そしてテストモードのフラグを立ててユニットテストを行います。一カ所コードを変更する度に、DEBUG_MODE 定数をtrueにし、すべてのユニットテストを行います。何らかの意図しない副作用が発生していないことが確認でき、安心して開発が続けられます。
ユニットテストと総合的なテストのスパイラルで完成へ向かう
ユニットテストに合格したら、テストモードのフラグを下げて（DEBUG_MODE 定数をfalseにする）アプリケーションとして動作させ、総合的なテストを行います。こうして作成したsketchがユニットテストでも手動の総合的なテストでも要求した動作をするようになれば、アプリケーションの完成と考えます。
ユニットテストで各クラスを仕上げる
総合的なテストでアプリケーションとして動作することを確認する
前回学習した1.の内容と、今回紹介している2.の内容を交互に、あるいは並行して問題がなくなるまで繰り返すことで、アプリケーションはより良く成長し完成へ向かいます。
FacebookのCEOであるMark Zuckerbergは、"Done is better than perfect"（完璧な製品を作るよりも早く仕上げろ）と述べています。何を持って"Done"とするかについて、ここでは上述2つのステップで満足いく結果が得られたら、を提案します。少しぐらい不満な点があったとしても、テストに規定した動作をするのならば"Done"（仕上がった）としましょう。
ベータテスト
アプリケーションの正式公開前には、開発者以外の限られたユーザによるユーザテストを行いましょう。このようなテストをベータテスト と呼び、正式公開前のソフトウェアをベータ版と呼びます。ベータ版に対して、開発者が作成中のソフトウェアをアルファ版と呼びます。開発者が開発中のソフトウェアに対して行うテストをアルファテスト と呼びます。
ベータテストは、できるだけ複数の人にお願いし、複数の手と目でテストしましょう。その際、どんな操作を行ってほしいかの具体的なリストがあると、テストを依頼された人が助かります。ここもテストファースト （まずテスト）です。加えて、自由に使ってみてもらい、製作者の想定しなかった問題をあぶり出します。「 作った人が一番良く分かっている」ということは決してありません。製作者の死角を指摘してもらうことが必要です。
ユーザからの改善要望によるバージョンアップ
ベータテストで一定の成果を得られたら、積極的にソフトウエアを公開しましょう。
個人情報を預かるようなソフトウエアでない限りは、完璧になるまで公開しないとか、使わないというのはナンセンスです。作成者には思いもよらなかった改善点、使ってみて初めて分かる問題点などがあるからです。間違いや問題が発見されるのは恥だなどと思わず、どんどん公開し使ってもらいましょう。明らかになったり指摘を受けた問題や改善点をアプリケーションに反映してバージョンアップ版を公開しましょう。石は磨かなければただの石ころです。磨いて、削られることで美しいものに変身するのです。
品質保証の手段と安心感のある開発を手に入れよう
前回、そして今回のまとめとして、これまでの内容を振り返ります。
テストを伴わないソフトウエア開発は「品質保証」の根拠がありません。最低限これだけのテストに合格したのだと示すことができるのが、テスト駆動開発の一つ目の利点です。
さらに、テスト駆動開発の手順を守っている限り、開発中のテストのし忘れはありません。プログラマは安心して次のバグフィクスや機能開発へ進めます。この安心感のある開発ができることが、テスト駆動開発の2つ目の利点です。
まずテストを記述し、テストに合格するようコーディングすることは、ただ単にコーディングすることに比べて手間が増えています。テスト駆動開発をしたことのない人にとっては「面倒くさい！」という思いが先に立って、実行の障害になっていることと推察します。しかし、その障害を是非乗り越えることを強くお勧めします。上記2つの利点が大変大きいからです。一度これらを享受すれば、決して元のテスト駆動開発のない状態に戻ろうとは思わないことでしょう。
プログラマの必須習慣として、これからの開発に活用してください。
演習
演習1（難易度：middle）
テスト駆動開発で健康管理アプリケーションを完成してください。PersonalDataクラスへのコード追加や、追加したコードに対するテストコード、UIのコードも作成してください。
まとめ
テスト駆動開発とは何かを学びました。
テスト駆動開発を用いて小さなアプリケーションを作りました。
学習の確認
それぞれの項目で、Aを選択できなければ、本文や演習にもう一度取り組みましょう。
テスト駆動開発の目的とメリットが理解できましたか？
理解できた。気持ちよく納得した。
理解できた。しかし、今ひとつスッキリしない。
理解できない。
テスト駆動開発を使えるようになりましたか？
使えるようになった。自分のプログラミングにも活用できそうだ。
本文の例を理解することはできたが、自分のプログラミングに活用できる気がしない。
本文の例が理解できない。
参考文献
『ソフトウェアテスト293の鉄則』（ Cem Kaner, James Bach, Bret Pettichord 著、テスト技術者交流会 翻訳、日経BP社 ）
日本と異なり米国においてソフトウェアテストは1つの独立した「職種」です。その世界で長年現場経験を積んだ著者らがまとめた各鉄則は、ソフトウエアを開発する私たちにとって大変有益です。
演習解答
コード例を示します。
ところで、この解答コード例にはリファクタリングのしどころ満載です。例えば、getYourWeightメソッドなんて、getWeightで十分です。また、UIがらみでたくさんのマジックナンバーがちりばめられています。結局アスリートかどうかなんて使っていません。余力のある方はリファクタリングに取り組んでください。
