【ソフトウェアテスト】単体テストは機械的に確認できる

その名の通り、"単体"と言われているように、原則として対象は最も小さな単位のプログラムソース（モジュール）でなければならないとされています。

ですが、古いプログラム言語と異なり、ここ数世代のプログラム言語では最小過ぎてもテストが実施しにくいケースも多く、特にＥＤＩ（統合開発環境）で開発せざるを得ないプログラム言語の場合は、ＥＤＩ自体にデバッグ機能も付いているため、「その使い方しか知らない」「利便性が良すぎて、もう元には戻れない」と言った事情から、ある程度のまとまりを「最小」とせざるを得ないこともあるようです。

どちらにしてもプロジェクト内で定めた「最小」単位で、まずは動作を保証することが絶対条件となります。

なぜなら、単体テストレベルでの動作確認が行えていないレベルのプログラムをどれだけ組み合わせたところで、まともに動く保証がないだけでなく、組み合わせてしまったがために複雑化しすぎて、問題発生時にその原因を特定することが困難となってしまう可能性があるからです。

テストの考え方やテストツールの使い方などにおいて、

　「楽だから」
　「効率的だから」

というだけでなく、本来テスト工程が目的としている「それぞれに求められている品質を保証するため」に最適かどうかを検討しなければなりません。

そして単体テストは、多くの場合「どんな動作であるべきか？」と言うロジックを保証したいのではなく、「動くのかどうか？」という"動作"そのものであることが求められています。

「どんな動作であるべきか？」と言う観点はソフトウェア品質における"機能性"のなかの"合目的性"に該当します。これは、本来結合テストの観点であるべきなのです。

開発プロジェクトの中で「詳細設計」工程の手順を踏んでいる場合は、詳細設計書に記載された処理と違わない結果となっていることを保証することが目的となるでしょう。

網羅性確認とは

網羅性確認とは、「自分で作ったプログラムに対して責任を持つために、隅から隅まで確かめる」ことを指します。その名の通り、すべてが網羅されていなくてはなりません。網羅性についてはいくつかの分岐レベルが設定されており、どこまで確認すべきかについてはプロジェクトによって異なってきます。

大手SIerでは、概ね「C1:分岐網羅」までの確認、動作保証を行うのが単体テストの粒度となっているのではないでしょうか。「C2:条件網羅」は盲目的に全てを実行すると、業務上不要な組み合わせまで実施してしまうケースもあるので、よほど精度の高い設計ができない限りはあまり実施する機会はないかもしれません。

ただ、個人的には「テスト設計」において、Ｃ２まで全網羅したテストケースを作成することは推奨します。そこから実際に「テストするか、しないか」は優先度等の検討によって間引いてもいいでしょう。しかし、検討時点で全網羅できていないテストケースでは、

　そもそも観点から漏れていた

という事態を招きかねませんし、「漏れてないよ」と証明するエビデンスが残らないため、決して品質の『保証』には至らないからです。テストケースはＣ２まで全網羅して、そこから不要なもの、優先度の低いものを消し込んでいく…を意識しましょう。そもそも、その方が機械的に作成できて、手間はかかりますが、思考的には楽です。