単体試験のテストパターンを早く作るのコツを教えてください

Question

お世話になります。
C言語の単体試験のテストパターンを作ることが苦手で、
ひとつの関数で遅いと2日3日かかっているため周りに迷惑をかけてしまっています。
皆さんがテストパターンを作る際、
具体的にどのように行っているのか、どのようにして作業を時短して1日の間に多くのテストパターンを作成しているのかを教えていただきたいです。

時間がかかる関数の傾向は同じ変数が何度も登場をして、
最終的にどこに何の値が入っているのか分からなくなるものです。(下記の例のようなものです)
そこからifの入れ子が多いものや境界値のチェック、演算、上下限のチェックとかが入ってくると思考停止してしまいます。

今行っている対策は、ソース内の同じ変数に色をつけて分かりやすくして少しでも混乱を減らすことのみで、
私が思いついたのはこれのみです。
仕事が遅く、周りに迷惑をかけているため本当に苦しいです。
下記のパターンを例にしなくとも、
コードを見たら自分はまずこうしてテストパターンを考えてるでも結構です。
どうかお知恵をお貸しください。
よろしくお願い申し上げます。

例)(いろいろと省いているので分かりづらかったらすみません)
Aのソフトにある関数
hensuu = hensuu2
anohensuu_1 = kansuu1(hensuu/10)

if(anohensuu_1 > 10)
{
bnohensuu = kansuu2(hensuu2100);
}
else if(result == 1)
{
bnohensuu2 = kansuu2(hensuu21000);
}
else
{
bnohensuu3 = kansuu2(hensuu2*10000);
}

Bのソフト(定数の記述がある)
#define hensuu2 10.0

Answer 1

単体テストならテスト対象の関数の作者は普通ご自分かと思います.
もしそうでしたら, 関数の規模がテスト作成力とあっていないと思いますので, もっと関数を細分化するという方法もあります.

Comments

[hasune]

すみません、記載していませんでしたが、単体テストは業務で行っています・・・。

[gentaro]

業務で行う単体テストは通常対象のコードを書いた本人が作成するものだ、という意味でおっしゃっているんだと思いますが。（私もそう思います）

[hasune]

>gentaroさん

そういう意味だったのですね。すみません。
今まで他人が書いたコードの単体テストしかなかったので、
それが普通だと思っていました。

[jimbe]

作者は他の方でしたか, 失礼しました.
gentaroさんフォローありがとうございます.

Answer 2

そこからifの入れ子が多いものや境界値のチェック、演算、上下限のチェックとかが入ってくると思考停止してしまいます。

テスト対象のコードの複雑度にもよると思いますけど、思考停止しちゃうのは一度に複数のことを考えるからじゃないですか？ひとつのテストコードで複数の確認をしようとしてたり、とか。

単体テストなんて所詮は「入力値－期待値」のペアを作っていく作業に過ぎないのだから、まずひとつの入力値に着目して、その値の取りうる範囲でテストが必要な項目（最小・最大値とかゼロ値とか境界値とか）を列挙し、他の入力値はテストが通る最低限の値を入れてばーっと組み合わせを作る作業を繰り返せば、結構なカバレッジのテストはできると思います。

それが終わってから、複合条件をひとつひとつ洗い出してテストを書いていけばいいので、思考が停止してても機械作業でできるんじゃないかと思いますが。

Comments

[hasune]

>思考停止しちゃうのは一度に複数のことを考えるからじゃないですか？
仰る通り、一度に複数のことを考えないといけない場合に頭がパンクしてしまいます。
例として挙げたような、関数の中に何度も同じ変数があった場合は辛いです。

＞ひとつの入力値に着目して、その値の取りうる範囲でテストが必要な項目（最小・最大値とかゼロ値とか境界値とか）を列挙し、他の入力値はテストが通る最低限の値を入れて
この部分を読んで思ったのが、
大きな関数で同じ変数が登場するとテストが通る最低限の値が何なのか分からなくなる時が多いです。
だから機械作業にできていないのかも・・・。
メモをしながら作業をしていますが、
そのメモの仕方も悪いのかもしれません・・・。

Answer 3

1. テキトーにテストをいくつか書く
2. カバレージを取りつつテストする
3. 2の結果から、通ってないトコを見つけ、そこを通るテストを追加。
4. 2に戻る。

ってやってます。

Comments

[hasune]

単体テストというのはシンプルな話にすると、
epistemeさんのコメントになるのですね。
私は難しく考えすぎなのかもしれません・・・。

コードを見た時に分かる箇所からテストパターンを考えるのはありかもしれません。

[episteme]

その例だとif文ふたつあるから、パターンは高々4通り。
てかそもそも、コードからテストを作っちゃダメ。仕様から作るべし。

[hasune]

今回の例だと、私は変数(特に同じ変数)に注目していました。
if文がいくつあるかをまず見るのは私にはない視点でした。
それが頭がパンクする一因だったかもしれません。コメントありがとうございます！

仕様書ですが、仕様書が読めない(英語＆図しかない)ので読んでませんでした・・・。
仕様書は大事ですね・・・目を通すことからはじめて慣れていきます。

[episteme]

コードからテスト作ったら全部成功するに決まってるっしょ?
検証したいのは「思った通りに動くか」であって「作った通りに動くか」ではないんだから。