シリーズ「開発の初めから順番に書いていってみる」の続きです。
設計手順には、要求分析、外部設計、内部詳細設計・プログラミング、単体テスト、結合テスト、総合テスト、運用テスト及び運用とあります。
（バックナンバーは、ここ http://www.geocities.jp/xmldtp/index_kaihatsu.htm 最近更新しました）。
前回で、ここの順番で言う「３．ドライバ、スタブ、テストデータの作成」が終わりましたので、今回は次の、「４．実際にテストする」です。
■単体テストの実施（１）デバッグモードで目視
単体テストは、ホワイトボックステストであるとすると、プログラムの分岐あるいは命令を通ったか、をしらべることになります。
これは、デバッグモードで実行して、デバッガで１行１行、確認しながら行えば、まあ、できます。
しかし、テストの場合、本当に、テスト項目を実施した、今回の場合、本当にそこを通ったということを証明するもの＝エビデンスが必要です。
画面コピーをとる・・・というのも、大変です。
どうしましょう。
■単体テストの実施（２）ログを入れる
ということで、エビデンスまでとるとなると、ログを入れるということになります。
ログを分岐点にいれて実行、ログを取得すれば、ログから、通ったか通らないかわかるので、エビデンスとすることができます。
ただし、アスペクト指向でもない限り、プログラムを作り終わったあとに（テストするときに）ログを入れるというのは、プログラムを直さないと出来ないわけで・・・
っていうわけで、ログをいれてエビデンスとする場合には、コーディング規約で、ログをいれるところをきめて、プログラム作成中に、ログを入れておくのが、のぞましいです。
■単体テストの実施（３）どっちもめんどうなので。。
でも、どっちにしろ、めんどうです。
JUnitでは、モジュール内はブラックボックスとして、入力値を変化させ、その出力結果をログに残すことにより、単体テストとしています。
これが、単体テストか？ホワイトボックスこそが、単体テストではないのか・・
という意見もあるかと思いますが。。。
■結果とエビデンスをのこす
で、結果に関しては、記入するところがあるのでそこに記入し、必要なエビデンスをのこします。
というように実施するわけです。
で、うまくいけばこれでおしまいなのですが、たいていは巧くいきません。
バグが、でます。
次回はそのバグについてです。
アクセス
トータル
ランキング
