単体テストの効率化を考える(18)
テスト設計書の書き方
(シングルポインタの場合)

2022年11月13日

どもです。

前回のエントリに引き続き、ポインタ引数のテストドライバについて書きます。

今回のエントリは、ポインタ引数への入力のテスト設計書での書き方、表現の仕方について考えてみます。

1. 単体テストの環境

今回のエントリでは、以下の環境で作業を行います。

2. 問題点

以前の投稿で、テスト設計書、特にデシジョンテーブルについて書きました。
ここで前回のエントリのサンプルコードに対応する設計書を考えると、どうにも書けません。

//コードの再掲
void test_driver()
{
	int arg = 10;
	int result = sample_function(&arg);

	ASSERT_EQ(100, result);
}

このテストドライバに対するデシジョンテーブルは、素直に考えると以下のようになります。

このデシジョンテーブルを見ても、多くのエンジニアは「？？？」となると思います。

3. 解決案

では、どのようにテスト設計書を書けば良いのでしょうか？

本エントリでは、

ポインタの実体に対応する変数を用意しておく

という「最もシンプル」である(と、考えられる)方法について考えてみます。

3.1. ポインタの実体の変数の名前

ポインタに対する実体の変数を用意しておくとした場合、変数の命名規則が問題になります。
場合によっては、変数名が重複してしまう可能性があります。
そこで本エントリでは、「重複が起こりにくい命名規則」として、

先頭に「_」(アンダーバー)を付与する

という規則を採用して、話を進めてみます。

具体例をあげると、「arg」というポインタ変数に対応する実体を示す変数の名前は、「_arg」とします。

この変数を用いたテスト設計書は、以下のような書き方になります。

ポインタ変数には、「実体に対応する変数」のアドレスをセットします。
そして、テストで参照する具体的な値については、この「実体」の値としてデシジョンテーブルを作成します。

このデシジョンテーブルであれば、テストドライバは実装ができると思います。

3.2. ポインタの実体の変数
(配列の場合)

先述したテスト設計書の書き方は、ポインタの実体が配列ではない場合は問題ありません。
しかし、ポインタの実体は、多くの場合配列などの領域です。
そのため、この書き方では不十分な場合が多いです。

ではどうするか？
簡単です。
実体を配列のように書きます。

これにより、ポインタの実体が配列であった場合にも対応ができます。

3.3. ポインタの実体の変数
(配列の場合/期待値の場合)

最後に、テスト対象関数内で、引数で渡したポインタの内容を書き換える場合を考えます。

テスト対象関数内でポインタの実体を書き換える場合、このポインタの実体は「期待値」となります。
その場合、テスト設計書におけるポインタの実体の変数は、期待値(出力)に記載されます。

また、入力の場合と合せて実体の入力値を書いておく、というのも「アリ」だと思います。

4. まとめ

今回は、ポインタ引数への入力のテスト設計書での書き方について、考えてみました。
結論をまとめると、以下のようになります。

• ポインタの実体に対応する変数を用意する。
• ポインタの実体に対応する変数の命名規則を決めておく
  • 他の変数と重複しないような命名規則にすること
  • 例：ポインタ変数の前に「_」を付与する
• 設計書(デシジョンテーブル)は、ポインタ引数には実体の変数のアドレスを設定するよう記述する
• テストで使用する値は、実体の変数の値として設計書(デシジョンテーブル)を記述する。
• ポインタの実体が配列の場合には、実体に対応する変数を配列として記載する。
• ポインタが出力になる場合には、出力/期待値側にポインタの実体/値を記載する。

「変数の命名規則を決めておく」必要があるため、課題は残ります。
それでも、ポインタ引数への入力のテスト設計での書き方に対するある程度の方針は示すことができたかと思います。

なお、「単体テストはコードを実装したエンジニアが実施するから、この問題は発生しないのでは…？」と思ってはイケマセン♪

今回のエントリが誰かの助けになれば、幸いです。

ではっ！