見出し画像

単体テストはひとりでこっそりと(ソフトウェア分析)

単体テストはどうしているでしょうか。単体テストはひとりでこっそりとやっているでしょうか。それも軽く気楽にやっているでしょうか。そう、それでいいのです。コストは最小限に実施するのがいいのです。自動化は当たり前、既存のテストケースの再利用も当たり前です。単体テストは結果だけでいいのです。単体テストでどこまでカバーしたのか、それを問題なくパスしたのかの結果だけでいいのです。そしてこれらを満たすには、単体テストはツールを使うのが必須です。図引用元:IPA ソフトウェア開発分析データ集 FAQ

単体テストとは

単体テストとはプログラムの実行最小単位を対象とするテストです。Javaであればメソッド関数、Lispであれば関数、FORTRANであればサブルーチン、Pascalであればプロシージャを対象にしたテストです。
 
実行最小単位に対する入力(引数や実行前の状態)と期待される出力(値や実行後の状態)のペアでテストをする単純なものです。入力を与えて最小実行単位を実行し、期待される出力が出れば、いいだけです。
 
もしあなたが状態を持たない優れた関数型プログラミング言語を使っているのであれば、引数と値だけで単体テストは実施できます。これは簡単で素晴らしいものです。ぜひ、関数型プログラミング言語を使いましょう(宣伝、終わり)。
 
単体テストはひとりでやるものです。プログラミングしたプログラマが自分自身でやるものです。そして結果だけを伝えるだけでいいのです。その結果として「オールグリーン」、つまりすべての単体テストでパスしたという結果だけを上司に報告します。これが単体テストです。

単体テストの正しい歩き方

単体テストは単純なものですが、それでも入力と出力の組み合わせは爆発的に多くあります。すべての組み合わせテストはできません。そこは色々なテクニックを使って、適当に減らしましょう。もちろん科学的な方法がいいですが、経験や勘によるもの、または神や悪魔に祈るなどのオカルト的な方法もありますので、取捨選択してください。
 
単体テストは数で勝負しません。網羅基準、カバレッジで勝負します。どの範囲をどこまでカバーしたかで競います。そしてこれだけで勝負します。例えば、C0と呼ばれる命令網羅の基準があります。これは実行最小単位の命令文を1回以上テストしたことを保証するものです。
 
これが単体テストの世界です。ようこそ、単体テストの世界へ。でも、ひとりで歩いてください。

単体テストのずるい手の抜き方

単体テストはカバレッジで勝負するのが常套手段ですが、カバレッジを適用できない場合もあります。例えば、単純なC0命令網羅であっても、難しいことがあります。一番の敵は例外処理です。すべての例外処理の命令をテストするのは、すべての例外を発生させる必要がありますが、無理な場合があります。特にJavaなどのように木目細かに例外をハンドリングするタイプの言語であれば、面倒です。
 
このような場合は単体テストでは保留にしておき、次のテスト、例えば結合テスト、システムテストで実施するという方法もあります。悪魔の囁きにちかいですが、ご参考までに。

単体テストの賢い進め方

単体テストはコストを掛けずに行うのが吉です。このためには、ツールによる自動化や既存のテストケースの再利用など、あらゆるテクニックを駆使して、手抜き、いえ、効率的に実施しましょう。手抜きするためには、どんなにコストを掛けてもいいのです。将来はきっと安泰です。
 
単体テストは入力をランダムに選ぶランダムテストではありません。入力をどのように選ぶかが重要です。これで単体テストの効率化につながります。同値分割は基本ですが、これも発見的手法が必要になります。機械的ではありません。同値をどのように想定するかが難しいです。ここは結局、経験と勘かもしれません。
 
同値分割で選ぶ値を境界値にするというのも上記のテクニックです。いじわるな人ほど、細かいことが気になる人ほど、単体テスト、引いてはテストに向いています。ということで、いじわるしましょう。
 
ということで今日の結論。「単体テストは自動で」以上です。

マンガFAQの引用元:ソフトウェア開発分析データ集2022 | 社会・産業のデジタル変革 | IPA 独立行政法人 情報処理推進機構


よろしければサポートをお願いします!