Japan Symposium on Software Testing 2004 はじめてみようテストファースト JaSST ’ 04 チュートリアル２ ２００４年１月２８日 10:00 ～ 佐賀大学 大月 美佳 … こと、みかまま 東京コンファレンスセンター 品川.

Presentation on theme: "Japan Symposium on Software Testing 2004 はじめてみようテストファースト JaSST ’ 04 チュートリアル２ ２００４年１月２８日 10:00 ～ 佐賀大学 大月 美佳 … こと、みかまま 東京コンファレンスセンター 品川."— Presentation transcript:

1 Japan Symposium on Software Testing 2004 はじめてみようテストファースト JaSST ’ 04 チュートリアル２ ２００４年１月２８日 10:00 ～ 佐賀大学 大月 美佳 … こと、みかまま 東京コンファレンスセンター 品川

2 Japan Symposium on Software Testing 2004 2 おおまかな流れ テストファーストとは何か – テストファーストで何が嬉しいの？ – テスト駆動型開発の流れ テストファーストの実際 –xUnit と CppUnit –CppUnit を使うには –CppUnit の手順と演習問題 質問など (10 分 ) 休憩 (5 分 ) επιστημη ( えぴすてーめー ) さんにバトンタッチ

3 Japan Symposium on Software Testing 2004 3 テストファーストとは Kent Beck 提唱 eXtreme Programming(XP) のプラクティス ( 実践項目 ) のひとつ XP については、第 3 章 (p. 89 ～ ) を参照 単体テストを最初 (first) に書く 実装はその後 ( テストの前には書かない ) テスト駆動型開発に発展 テストに駆動される形になるため 「テスト駆動開発入門」 ISBN: 4894717115 ケント・ベック

4 Japan Symposium on Software Testing 2004 4 テストファーストの利点 バグの早期発見 – テストで押さえられる範囲において ( 完全ではない ) 安心度が高まる – 変更に対する心理的抵抗が下がる 実装前にインターフェースの仕様が明確になる – どのような使われ方をするかから考える – どのような使われ方がやばいか、も考えるとなお良し 楽しい – 小さな挑戦をリズム良く繰り返せる 後でテストを見ると使い方が分かる – サンプル駆動型、と言っている人も

5 Japan Symposium on Software Testing 2004 5 テスト駆動開発の流れ 詳細は 1.3.1 項 (p. 24 ～ )

6 Japan Symposium on Software Testing 2004 6 xUnit テスティングフレームワーク – テストのドライバ → ボトムアップに向いている – ホワイトボックスというよりはブラックボックス Java 言語用から各種言語へ –Junit, CppUnit, CUnit, NUnit, PerlUnit, RubyUnit, … – 総称して xUnit

7 Japan Symposium on Software Testing 2004 7 CppUnit C++ 用のテスティングフレームワーク – 他にもある (CppUnit-x) –cppunit.sourceforge.net 今更新が停滞中 …

8 Japan Symposium on Software Testing 2004 8 CppUnit を使うには C++ 開発環境 –Visual C++ 6.0 –Borland C++ –GNU C++ (+ make or automake) CppUnit インストール – インストールの詳細は、 2.2 節 (p. 36) 環境設定が必要 –Visual C++ の環境設定 → 2.4.2 項 (p. 80) –GNU C++ (+ make) での環境設定 → 2.4.1 項 (p. 74)

9 Japan Symposium on Software Testing 2004 9 CppUnit を使ったテスト駆動

10 Japan Symposium on Software Testing 2004 10 CppUnit 基本手順 1. 新しいテスト対象 1. テスト対象クラスを空で作る ( 定義のみ ) 2. テストクラスを作る ( テンプレート * → 5.2.1 項 p.239 ～ ) 3.Main 部を作る ( テンプレート → 5.2.2 項 p.241 ～ ) 4. 動作確認をする 2. テストケースの追加 1. テスト関数を追加・実装する (ASSERT マクロ一覧 * → A.4 節 p.275) 2. テストが失敗することを確認する 3. テスト対象クラスを実装する 4. テストが通ることを確認する 5. リファクタリングする

11 Japan Symposium on Software Testing 2004 11 基本手順サンプル Visual C++ にて実演

12 Japan Symposium on Software Testing 2004 12 演習 1 CGI を処理する C++ プログラムを作成するために、 CGIInput, DataProcesor, HTMLOutput という 3 つ のクラスを作ることにしました。 – 各クラスのヘッダファイルを作成しましょう » メンバ変数、関数はない状態で – 各クラスのテストクラスのヘッダファイルを作成しましょう » テストの中身はない状態で –3 つのテストクラスを駆動する TestMain.cpp を作成しましょう – ビルドできるように構成しましょう »VC++6.0 ならばワークスペースを、 g++ ならば Makefile を – ビルドして結果を確認しましょう

13 Japan Symposium on Software Testing 2004 13 演習 2 演習 1 で作成した各クラスに以下の関数を実装し ます。必要だと思うテストケースを書き出してみ てください。 –char *CGIInput::getarg(char *argname) »CGI の変数名を文字列 (argname) で指定すると、その値を文字列で返 す –char *DataProcesor::addition(char *xstr, char *ystr) »2 つの整数値を文字列 (xstr, ystr) で受け取り、その結果を文字列で返 す » 与えられた文字列が数値でない場合はエラーメッセージ (Not Number) を返す –void output(char *message, ostream & os) » 表示したいメッセージを文字列 (message) で受け取り、指定された出 力ストリーム (os) に HTML フォーマットで書き出す。

14 Japan Symposium on Software Testing 2004 14 テストケースの実装 テストケースをテストクラスの関数で実装する – 元来はテストケース = テストクラス – クラス数が爆発、混乱 → アダプタパターンで 1 クラスに集中 –setUp, tearDown は各テスト関数の実行前と後にそれぞれ実行 この前後 アダプタ

15 Japan Symposium on Software Testing 2004 15 ASSERT マクロの使い方 ヘッダ cppunit/TestAssert.h – 明示的に読み込む必要はあまりない Visual C++ にて実演 –CPPUNIT_ASSERT( 条件 ) –CPPUNIT_ASSERT_MESSAGE( メッセージ, 条件 ) –CPPUNIT_FAIL( メッセージ ) –CPPUNIT_ASSERT_EQUAL( 期待した値, 実際の結果 ) –CPPUNIT_ASSERT_EQUAL( メッセージ, 期待した値, 実際の結果 ) –CPPUNIT_ASSERT_DOUBLES_EQUAL( 期待した値, 実際の結果, 誤 差 )

16 Japan Symposium on Software Testing 2004 16 演習 3-1 演習 2 の関数 CGIInput::getarg について以下のテ ストを実装してください – 環境変数 REQUEST_METHOD に "GET" が、環境変数 QUERY_STRING に "x=12&y=6&submit=submit" が与えられたとき、 CGIInput::getarg("x") が "12" 、 CGIInput::getarg("y") が "6" 、 CGIInput::getarg("submit") が "submit" 、という文字列を返すかど うかチェックするテスト – 環境変数 REQUEST_METHOD に "GET" が、環境変数 QUERY_STRING に "x=3&y=102&submit=submit" が与えられたと き、 CGIInput::getarg("x") が "3" 、 CGIInput::getarg("y") が "102" 、 CGIInput::getarg("submit") が "submit" 、という文字列を返すかど うかチェックするテスト

17 Japan Symposium on Software Testing 2004 17 演習 3-2 演習 2 の関数 DataProcessor::addition について以下 のテストを実装してください –2 つの文字列 "12", "21" を渡すと、文字列 "33" を返すようなテスト –2 つの文字列 "4", "102" を渡すと、文字列 "106" を返すようなテス ト –2 つの文字列 "-6", "10" を渡すと、文字列 "4" を返すようなテスト –2 つの文字列 "3", "-10" を渡すと、文字列 "-7" を返すようなテスト –2 つの文字列 "A", "-10" を渡すと、文字列 "Not Number" を返すよう なテスト

18 Japan Symposium on Software Testing 2004 18 演習 3-3 演習 2 の関数 HTMLOutput::output について以下の テストを実装してください – 文字列 "result" が与えられたとき、与えられた出力ストリームに、 以下のような文字列を書き出すテスト Result Result: result – 文字列 “12” が与えられたとき、与えられた出力ストリームに、以 下のような文字列を書き出すテスト Result Result: 12

19 Japan Symposium on Software Testing 2004 19 実装とリファクタリング 最初はダミーコードから – 環境変数 QUERY_STRING に “x=12” で getarg(“x”) なときに、 char *getarg(char *argname) { return “12”; } –addition(“1”, “2”) なときに、 char *addition(char *xstr, char *ystr) { return “3”; } –output(“test”, os) なときに、 void output(char *message, ostream &os) { os << “test”; } 重複の削除 ( リファクタリング ) – コードで重複している部分を置き換えていく “3” → _itoa(3) → _itoa(1 + 2) → _itoa(atoi(“1”) + atoi(“2”)) → _itoa(atoi(xstr) +atoi(ystr)) – 面倒くさくても 1 ステップづつやるのがこつ –C++ の場合メモリ管理が入る

20 Japan Symposium on Software Testing 2004 20 演習 4 演習 3-1 ～ 3-3 で実装したテスト関数をクリアする コードを、ダミーコードから 1 段 1 段リファクタリ ングしながら実装してください

21 Japan Symposium on Software Testing 2004 21 テストを書けばいいというものではな い 書かないよりは書いた方がまし でも、今あるテストでは対処できない例を考えているか？ テストに関する知識があれば鬼に金棒 – 境界値分析や状態の組み合わせなどの技法 – 開発環境の差異 – 並列環境や分散環境への対応 などなど 開発者とテスト技術者との知識交流 があるといいのではないか

22 Japan Symposium on Software Testing 2004 22 演習 5 演習 3-1 ～ 3-3 では対処できない例を 1 つ以上挙げ、 それらに対するテストコードを追加してください。 また、このテストコードをクリアできるコードを 実装してください。

23 Japan Symposium on Software Testing 2004 23 最後に より進んだ利用に向けて – 自動生成 / 支援環境 河童プロジェクト – モックフレームワーク C++ 用 → MockPP –GUI 特に Web HttpUnit, 開発者とテスト技術者の交流を – よりよいソフトウェアを作るために