前のブログで書いた
Excelなんかの試験（テスト）仕様書とJunit等のユニットテストの関係（その１）
の続きです
■■ 前のブログの内容
「そもそも、試験仕様書に書く項目を考える」では、仕様書に書く内容について書いて、とくに
・テスト内容
ここが、２つないし、３つにわかれる場合もある
３つの場合は、テストの内容、テストを行う（前提）条件、予想される結果
ということを書きました
「Junitなんかのユニットテストの考え方について、考えてみる」では、Junitなんかが、契約による設計（DbC）にもとづいていて、設計内容（＝テスト内容）は、事前条件、事後条件、不変条件にわけられるという話をかきました。
それらのことの詳細は、こちらをどうぞ http://www.javaroad.jp/java_exception4.htm
「仕様書（内容３部構成）と、契約による設計の関係」では、その事前条件、事後条件、不変条件と、テスト内容について
事後条件が、「予想される結果」
不変条件（事前に満たすこと）を、「テストを行う（前提）条件」に、
不変条件（事後に満たしてること）を、、「予想される結果」に、
事前条件を「テストの内容」（テスト項目）に
書くとまとまるという話をかきました。
今回は、その具体的な書き方の内容や、仕様書の内容が３つに分かれていない場合の書き方などについてです。
■■ 具体的には、３つにどうやって分けて書くのか？
３つに分けて書くときは、
●テストを行う前提条件で、
・そのテスト対象の入力となる引数以外のことを書いておく
・引数を、あらかじめ、処理しないといけない場合は、そのことを書いておく
たとえば、「ＤＢのコネクションを確立しておく」とかについてです。
エビデンスは、ここで、値になっているものに対しては、ログに書き出す
（ある変数が、１００になっていることなんていうのは書く。
でも、接続してることなんていうのは、ログに書きようがないので、書かなくても、まいっか）
なお、ＤＢの値を変化させる場合は、ここで、変化前の値をログに書き出す
●テスト内容（項目）で
対象となるユニットの引数など、直接相手に渡す値について、書く
このとき、クラスの変数として渡す場合、なやむんだよねー。
だけど、その値が違うことによって、結果が左右されるんなら、それも、事前条件としていいんじゃないか。
エビデンスは、ここで、値になっているものに対しては、ログに書き出す
● 予想される結果
返り値や、変化している値（クラス変数などあれば）を書き出す
JUNITだと、これは、assertをいれているはずである
エビデンスは、ここで、「予想される結果」については、基本的に、かならず、ログに書き出す
ログに書き出せない場合、調査方法は、目視となり、エビデンスが存在しない（あるいはハードコピー）になる。
なお、ＤＢの値を変化させた場合は、ここで、変化後の値をログに書き出す
■■ ３つのものを、まとめて、２つまたは１つにする
で、テスト内容が３つでない場合は、こういうふうにすると、まとまる。
●予想される結果が、テスト内容と一緒の項目になっている
（テスト内容）のときに（予想される結果）となっていること
という文章にする。
【 例 】
テスト内容 引数 コード=1234
予想される結果 carrotとかえる
という場合
コード=1234のときに、carrotとかえること。
●前提条件とテスト内容が一緒の項目になっている
（前提条件）の場合において、（テスト内容）
として、テスト内容に書くとＯＫ
【 例 】
前提条件 商品マスタはＯｐｅｎ済み
テスト内容 引数 コード=1234
という場合
商品マスタはＯｐｅｎ済みの場合において、コード=1234のとき
●全部まとめて、テスト内容
（前提条件）の場合において、（テスト内容）のときに（予想される結果）となっていること
という文章になる。
【例】をまとめると
商品マスタはＯｐｅｎ済みの場合において、コード=1234のときcarrotとかえること。
で、実際に、試験仕様書に、このような文がかかれたとき、さっきの操作によって、事前条件、事後条件、不変条件についてわけて、それらの条件をJunitでやるユニットテストに反映させていくことになる。
つまり、テストのところでは、
・ユニットを呼ぶ前に、事前条件をセットしておき、
・不変条件、事前条件のassert を（してもしなくてもしなくてもいいけど、良い方法としては）して
・テスト対象を呼び出し
・結果を、事後条件としてassertする。
っていうことになる。
っていった、試験仕様書のテスト方法マニュアルを、あんまりもらったことないんだけど。。
（別にJunitでなくても、ドライバでも、ログの入れ方でも、同じ注意ということになる）
これ、決まってないと、試験仕様書と、テスト内容の対応というか、正当性が確認できないと思うんだけど。。どーなのどーなの。。
あ、もちろん、こうやって書くと、気がつくと思うけど、このユニットテスト＜単体テストっていうことになりますよね。
単体テストでは、契約による設計で言う
事前条件
事後条件
不変条件
にあてはまらない、副作用のテストをすることと、テストの優先順位決定上、中間生成物をログによってチェックすることが必要になるので。。
（つーか、このユニットテストだけだと、たぶん、基準の半分くらい、もっと少ないか？にしか、テスト項目がならない気がする。。。）
でも、それについては、話題がちがうんで、また別の機会にでも・・（覚えていたら。。）
アクセス
トータル
ランキング
