ユニットテストとは
- クラスやメソッドを対象としたプログラムを検証するためのテスト
- ソフトウェアテストの中では最も小さい粒度のテスト
- デベロッパーテストとも呼ばれる
ユニットテストを行う理由
自分の書いたコードに責任を持ち、不安なくソフトウェア開発を行うため
ユニットテストの特徴
- 万能ではない。クラスやメソッドの相互作業や機能の確認、品質の保証については、機能テストや受け入れテストなどで行うべき
- 不具合が減り、変更に強くなる面でいうと品質は高くなる
- プログラムとして実行できる仕様書となれる
- 自然言語で記述したテストのあいまいさを排除できる
- ユニットテストを書くと、自身が作成したクラスやメソッドの最初のユーザーになるため、使いにくいと感じたならば、設計や仕様に問題があると気づくことができる
- テストコードを書くのは、最初コストがかかるが、後でほぼコスト無しで何度でも繰り返し実行が可能なので、トータル的にコストの節約に繋がる
主流のテスティングフレームワーク(JAVA基準)
- JUnit：一番有名
- TestNG：JUnitとほぼ同等の機能を提供しているため好んで使う人もいる
テストケースとテストスイート
- 1つのテスト項目をテストケースと呼ぶ
- テストケースには「前提条件、実行する操作、期待される値や状態」が含まれる→どのような条件でどのような操作をしたならばこうなることが期待される
- ソフトウェアテストは複数のテストケースで構成されるが、何らかの形で似たテストケースをまとめる必要がある。このように、いくつかのテストケースをまとめたものをテストスイートと呼ぶ
テスト技法
- ホワイトボックステストとブラックボックステスト
- ホワイトボックステスト
- 内部のロジックを知っていて分岐などを考慮し可能な限りすべてのロジックを実行できるようにテストケースを設計する
- コードを理解しているプログラマがテストを行う
- ブラックボックステスト
- 外部仕様のみからテストケースを設計する
- ユーザ受け入れテストや機能テストなど、比較的に大きな粒度のテストで採用される
- プログラミングの知識よりも業務知識などが重要
- ホワイトボックステスト
- 同値クラスに対するテスト
- ブラックボックステストに分類される
- 同様の結果をもたらす値を同値クラスとしてグループ化し、テストデータを選択する技法
- 例えば、
- 飲み物購入ボタンが「点灯」「点灯しない」「点滅」の3つのパターンを持つ自動販売機があるとする
- 投入金額が120円以上の場合はボタンが点灯する、未満の場合は点灯しない。ただし、120円以上であってもお釣りが足りない場合は点滅する
- 3つの結果について条件を満たすお金の組み合わせが同値グループを形成する
- しかし、この組み合わせは膨大な量となるため、適宜代表的な値を選ぶ必要がある
- 境界値に対するテスト
- 「年齢が20歳以下の場合～～になる」という仕様がある場合、20と21でテストをするが、20と21という境界値を選ぶ技法
- 一般的にはブラックボックステストに分類されるが、プログラムとテストコードを同時に実装する場合はホワイトボックステスト的に扱われる
ユニットテストで重要な3つのポイント
- テストを行う前提条件
- テストに用いる入力値や条件
- テストを行ったときに期待する値や動作
テストが行いやすいメソッドの特徴
- メソッドが戻り値を持つ
- メソッドの呼び出しの結果、副作用(オブジェクトの内部状態が変更されること)がない
- 同じ状態、同じパラメータで実行すれば、必ず同じ結果を返す
心がけること
- 自動化されたテスト―繰り返しいつでも実行できること
- 開発プロセスで実行自体を自動化すると尚更
- 不安なテスト―結果が一定でないテストを避けること
- 常にすべてのテストが成功している状態を維持することが望ましい
- ある条件下で失敗するテストを放置すると、テストが失敗しても気にしなくなってしまう。できる限り早めに解決すること
- ドキュメントとしてのテスト―仕様書として読めること
- 問題の局所化―テスト失敗時に問題を特定しやすいこと
- テストケースは、十分に小さな単位で可能な限り多く作るべき
- 小さくしないとテストが失敗になった時、原因分析にコストがかかってしまうため
- 不明瞭なテスト―可読性の低いテストコードは避けること
- テストコードは可能な限り、シンプルでわかりやすく記述するべき。テストコードもメンテナンスをするため
- 独立したテスト―実行手順に依存しないこと