データベース単体テストの中身の確認
さて、ここまでは単純にテストをするということだけを確認してきました。ここから先はデータベース単体テストの中身を少し詳しく見ていきたいと思います。具体的には、データベース単体テストを構成するための大きな要素である、スクリプトとテスト条件についてもう少し詳細を確認してみましょう。
スクリプト
データベース単体テストのスクリプトとは、先ほどまでに作成してきていたテストのためのSQL文などのことです。このスクリプトは表1に示すとおり、用途別に5種類のものが用意されていて、すべてT-SQLで作成します。
名前 | 作成単位 | 用途 |
テストの初期化 | テストクラスに1つ | テストクラスに含まれるすべてのテストの前にそれぞれ実行される、テスト初期化のためのスクリプト |
テスト前 | テストごとに1つ | テストごとに1つ作成することができ、テストが実行される前に特権コンテキストで実行されるスクリプト |
テスト | テストごとに1つ | データベース単体テストそのものを実行するためのスクリプト |
テスト後 | テストごとに1つ | テストごとに1つ作成することができ、テストが実行された後に特権コンテキストで実行されるスクリプト |
テストのクリーンアップ | テストクラスに1つ | テストクラスに含まれるすべてのテストの後にそれぞれ実行される、テストクリーンアップのためのスクリプト |
1つのテストクラスに2つのテストとテスト前後のスクリプトがあったとすると、それらは次の図21に示す順番で実行されます。
テストの初期化スクリプトとテスト前スクリプトは似たようなイメージを受けますが、作成する単位が違うことで用途が異なると言うところはポイントとしておさえておいてください。
データベース単体テストも拡張子がcs(またはvb)のソースコードファイルで出来上がっています。ソリューションエクスプローラでデータベース単体テストを右クリックして[コードの表示]を選ぶとC#などでできたソースコードを見ることができます。このコードを実際に見てみると、C#などで作成したソースコードのための単体テストを作成するときと同じような構造になっているため、ソースコードで簡単に編集ができるように思えてしまいます。しかし、実際には、通常の単体テストとは作り方が異なっていたり、デザイナで設定した情報はリソースファイル(.resxファイル)に格納されていたりと、手作業で編集するというのは、きちんと構造を理解していないと割と難しい作業になってしまいます。このため、まずはSQL文をデザイナで編集すると言うところだけでデータベース単体テストを行うようにすることをお勧めします。
テスト条件
初めてのデータベース単体テストを作成する過程で、図13で示していたようにテスト条件というものを設定しました。通常、単体テストを実施するときは、あるメソッドを呼び出すための準備を行い、対象メソッドを呼び出し、呼び出した結果状態の確認をするというステップを踏みます(Visual Studioの単体テスト機能ではAssert
クラスの各メソッドを利用してこの処理を記述します)。データベース単体テストで、この呼び出した結果状態を確認するための手段が、テスト条件になります。テスト条件は次の表2に示す6種類のものが用意されています。
テスト条件 | 解説 |
ResultSetが空ではありません | 実行結果の結果セットが空である場合に失敗となる条件 |
スカラ値 | 実行結果の結果セット内の指定した行、列の値が指定した値と一致しない場合に失敗となる条件 |
空のResultSet | 実行結果の結果セットが空ではない場合に失敗となる条件 |
結果不確定 | すべてのテストに追加される既定の条件で、テストがまだ実装されていないことを示す条件 |
行数 | 実行結果の結果セットの行数が指定した行数と一致しない場合に失敗となる条件 |
実行時間 | テストスクリプトの実行時間が指定した時間を超えた場合に失敗となる条件 |
これらのテスト条件は図13に示すようにそれぞれのスクリプトを編集する画面の下部にあるテスト条件のところから追加と削除を行い、図14に示すように、それぞれのテスト条件を選択した状態で、Visual Studioのプロパティウィンドウから編集していくことができます。
スクリプトに対して、これらの条件を組み合わせて設定しておくことで、例えば「30秒以内に10件のレコードが返ってきて、1行1列目の値は001である」といった実行結果の複雑な評価も実施することができます。
まとめ
今回は、Database Editionの持つデータベース単体機能について見てきました。この機能がなくても、Visual Studioに用意されている単体テスト機能を使って自分で、データベース接続、初期化処理、T-SQL実行コード、後始末、データベース解放などをソースコードとして記述すれば、テストが実行できないわけではありませんでした。しかし、本来やりたいことのための準備と後始末のためにそこそこの量のコードを書かなければいけないことは非常に非効率的であり、このような機能が用意されたことは非常に喜ばしいことではないかと思います。
今回は解説の対象から外してしまいましたが、Visual Studio Team System 2008 Database Edition GDRを使えば、SQL Server 2008を対象として同様のことを実施することもできます。それでもOracleには使えないというデメリットは残りますが、対象データベースがSQL Serverの場合にはぜひとも活用してみてください。