単体テストの書き方と重要性

単体テストの書き方

ソフトウェア開発では、後工程で手戻りが発生するほど工数がかさみ、悲惨な結果を引き起こすことが「よく」あります(苦笑)。

「動作確認レベルでいい」
「結合でバグを出すから大丈夫」

そんなふうに、最小単位である単体テストを軽んじているプロジェクトは、その時点で死に向かって歩き出していると思います。

単体テストコード

Visual Studio から単体テストを作成する際は、以下のブロックに分けてあります。

  • Arrange
    オブジェクトの初期化、テスト対象メソッドに渡されるデータの値を設定します。
  • Act
    設定されたパラメータでテスト対象のメソッドを呼び出します。
  • Assert
    テスト対象のメソッドの操作が期待通りに動作することを検証します。
よくありがちですが、せっかく単体テストコードを書いているのに、Assert を通すために都合よくデータを作成してテストを成功させても意味がありません。

あくまで要件通りの動作をしているかどうかを検証するのであって、「テストを通すためにテストコードを書いているわけではない」ことに注意が必要です。

カバレッジ(Coverage)とは

テストの網羅率。つまり、どのくらいテストしたかのことです。

  • C0:命令網羅
    条件分岐等、全部の箇所を通れば 100% となります。
  • C1:分岐網羅
    分岐の全組み合わせをテストすると 100% となります。
  • C2:条件網羅
    条件式の全組み合わせをテストすると 100% となります。全組み合わせなので、いくつも条件式があるようなメソッドだと 100% まで持っていくのは現実的ではなくなってしまいます。

単体テストで一番大切なこと


単体テストで大切なことは、カバレッジを 100% に近づけていくことだと思いがちです。

確かに、最小の部分での品質担保は必須ではあります。
しかし、C2 を 100% に近づけるためには、そもそも初めからメソッドの構造的な部分を意識して実装する必要があります。

できるだけ処理を分離して、メソッド間の処理が影響を及ぼさないように実装するにはどうすればいいのか。

単体テストコードを書くことが、そのきっかけになり、そこでの品質が高まることで、のちの結合テストで炎上してデスマーチ、という「あるある」な状況が回避できるのです。

このブログの人気の投稿

Excel で入力した文字に勝手に取り消し線が入る

コピーした行の挿入が表示されない時はフィルタされていないかチェック