PC-KEIBA Framework テスト プロジェクト

Step5:テスト プロジェクトの利用方法

※画面は「PC-KEIBA Framework クラスライブラリ Ver1.3.0」時点のものです。
ここまで、せっせと「テスト プロジェクト」のセットアップ作業を行ってきたわけですが
テスト って何のテスト?」 とか、
「他人が作ったプログラムのテスト、自分がやっても仕方がない」
などなど、その他、肯定的でない考えをもっている方がほとんどだと思います。

当サイトの管理人が何故、わざわざテストケースのソースを公開しているのか。テスト プロジェクト については様々な定義があるわけなのですが、この「PC-KEIBA Framework」においては

クラスライブラリの設計書

として位置づけしています。設計書としてヘタクソな日本語で、うだうだと説明を述べるよりも、実際の使用例としてソースを見てもらったほうが利用する側の理解も速いですよね(笑)。

とにかく実際のソースを見ながら、テスト プロジェクト が具体的に何をやっているのか見てみましょう。
前項までの手順を完了して、新しく作成された「Com.Pckeiba.Test.slh」を開きます。


画面右の「ソリューション エクスプローラ」から「MySqlSelectBufferTest」を開きます。


ここでは説明をわかりやすくするため、テキストエディタに「行番号」を表示する設定を行いましょう。
この設定は、実際にソフトウェア開発を行う場合のデバッグ作業にも役立ちます。
画面上部にあるツールバーメニューから [ ツール ] → [ オプション ] を選択します。


画面左下の「すべての設定を表示」にチェックを入れてから、ツリーメニューの
[ テキスト エディタ ] → [ すべての言語 ] → [ 全般 ] を選択します。
画面右下 [ 表示 ] セクションの「行番号」にチェックを入れて「OK」ボタンをクリックします。


テキストエディタの左に 1 ~ 1426 の「行番号」が表示されましたね。


次に、折りたたみ状態になっている25行目の「Methods」を開き(行番号すぐ右隣の [+] の部分をクリックします)、39 ~ 65 行目の「TestAdd1」メソッドを見てみましょう。


ここからようやく本題に入りますが、この「TestAdd1」メソッドでは何をやっているのかと言いますと、テストケースとして、

53行目:「MySQL」に接続するケースで(※このテストケース内では実際に接続しません)
54行目:「JVD_RACE_SHOSAI」テーブルの
55行目:SQL SELECT 文

…を作成します。

メソッドのコメントにも記述がありますが、これは「Add メソッドのテスト」です。55行目までは、このテストに必要なオブジェクトの準備を行っています。

※39~49行目の <summary></summary> のようなコメントの記述方式を「XMLコメント」と呼びます。
本題から逸れるため、ここでの説明は割愛しますが、興味のある方は「.NET XMLコメント」のキーワードでインターネットを検索してください。


57~60行目では「Add メソッド」へ値をセットしています。

57行目:「固定長 文字列型」の項目をセットします。
58行目:「日付/時刻型」の項目をセットします。
59行目:「数値型」の項目をセットします。
60行目:「可変長 文字列型」の項目をセットします。

62行目:予測される(期待する)値を変数に格納します。
64行目:「GetSql」メソッドの戻り値が正しいかどうか、実際に比較検証します。

すでに前項(Step4:NUnit GUI セットアップの手順)で確認済みですが、この「テスト プロジェクト」内のテストはすべて成功します。設計書の目的として、失敗するケースを公開しても仕方ありませんからね…。

もしも、「GetSql」メソッドが 62行目の期待値とは異なる値(SQL)を返してきた場合は、64行目の「Assert.AreEqual」メソッドが例外をスローし、このテストは失敗となります。

ところで、62行目の期待値(SQL)は SQL文 としては成立していませんね。
SQL のプログラミング経験がある方ならお分かりと思いますが「FROM 句」の指定がありません。
でも、いいのです。先ほども書きましたが、これは「Add メソッドのテスト」だからです。



PC-KEIBA Framework テストケースの作成基準

こんな感じで「PC-KEIBA Framework Ver.3.4.1」に対するテストケースを 7587ケース 作成しています。
これらのテストケースは、以下の基準を基に作成しています。

テストケースは部品単位(メソッド あるいは クラス単位)で作成する。
直前の例のように、テストケースの SQL が文法的に成立しているかどうかは問わず、各部品の精度を検証します。

テストケースは環境に依存しないケースのみを公開する。
例えば、管理人の開発環境には「PC-KEIBA Database」で使用可能な、すべてのデータベースがセットアップされています。が、このテストプロジェクトを実行するユーザーのPCにも、すべてのデータベースがセットアップされているとは限りません(※する必要はありません)。
要約すると「特定のアプリケーションが存在しないと成功しないようなテストケース」は作成していません。

public メンバのテストケースはすべて公開する。
上記の「環境に依存するケース」を除いて、値のみを返すようなメンバ(※定数など)であっても public メンバ のテストケースはすべて作成しています。たぶん(;´▽`A``

ちなみに「PC-KEIBA Framework」を利用して競馬ソフトウェアを開発する場合、この 7587ケース すべてをマスターする必要はありません。必要なときに目的の箇所にだけ目を通していただければよいでしょう。例えば「このメソッドの仕様はどうなっているのだろう?」と、いう時にです。
クラスライブラリ リファレンス と併せて、オリジナルの競馬ソフト作成に活用してください。



管理人的私見 ~ NUnit ~

ここまで 5ページに渡って テスト プロジェクト の概要をご紹介しましたが、いかがでしたか?最初にテストの結果だけを見れば「こんなことして意味あるの?」と思われる方が多いと思います。実際、私も NUnit を利用した開発に携わる前は、かなり否定的でした。

でも、いざ実践してみてすぐに理解できました。この NUnit を利用したテストがいかに効率的で、優れた開発手法であるかということを。ここでは書ききれないほどに実感し、多くの恩恵を被っています。

*Unit 系テストの賛否についてたびたび議論されることですが、NUnit を利用することによってすべてのバグが洗い出せるわけではありません。それは私自身も、最終的なアプリケーションテストで、NUnit のテストケースでは捕らえられない、あるいはテストのケースとして考慮が漏れていたバグに何度も遭遇し、修正を繰り返しています。

しかし、部品毎の精度を確認してから総合的なテストを行うことと、まともな確認を行っていないガラクタを集めて総合的なテストを行うのは、テストの品質としてどちらがよいでしょうか?押し付けするつもりは毛頭ありませんが、この記事を読んで「NUnit 使ってみようかな」と思う方が新たに現れれば幸いです。



NAgileで始める実践アジャイル開発

ここまでの管理人の説明では「プログラム テスト」や「ソフトウェアの開発手法」について多くの誤解を招く恐れがあります(笑)。また、ここまでの記事を読んで「NUnit」や「テスト プロジェクト」に興味を持たれた方は、以下のサイトを参考にしてください。


@IT連載:NAgileで始める実践アジャイル開発

テスト プロジェクトの利用方法は 以上です。


PC-KEIBA Framework テスト プロジェクト