テスト設計 第一部 ~ユニットテスト編~

テスト設計 第一部 ~ユニットテスト編~
■ 店頭より得で、予約しやすいオンラインショップ。
 → ドコモオンラインショップ
 → auオンラインショップ
 → ソフトバンクオンラインショップ

最新のiPhoneを得して乗り換えるなら、最大6万円のキャッシュバックがある
→ SMARTPHONE STORE

どうも、今年の夏はユニットテスト漬けだった大友です。

というわけで、「ホワイトボックス」と「ブラックボックス」の二つの視点から、ユニットテストの作り方を考察していきたいと思います。

前回、続編を望むコメントは特に無かった模様ですが。。。
この程度、想定の範囲内だよっ!(切ない)

前回のおさらい

前回の記事で「ホワイトボックス」と「ブラックボックス」の利点欠点を取り上げました。

ホワイトボックステストとは、内部の処理をすべて網羅することで、「誤字や変数参照ミス」などのケアレスミスや「正しくキャッチされていないエラー処理」などの異常系が正しく動くかどうかの問題を発見するためのテストのことです。
そのため処理完了の結果、ストアされる値が正しいかどうか、戻り値が正しい値かどうか、という部分は感知できません。

逆にブラックボックステストは処理の中身や流れは見ず、入力値に対する出力結果が正しいかどうかのみを確認します。

アチラを立てればコチラが立たず。
さて、一体どうやってテストを作っていけばいいでしょうか?

ブラックボックスの視点からテストを作る

ではまず、手始めに「完成した処理を実際に動かしたら、想定した答えがちゃんと返ってくるか?」ということを確認しましょう。

超シンプルな例を一つ。
ブール値を引数に、各々対応した数値を返す処理があったとします。

この場合、以下のような感じで関数に引数を渡してあげれば、result変数にそれぞれ結果が返ってきますね。

後はその返ってきた結果が「1」か「0」か「null」か、とそれぞれチェックしてあげればいいですね。
ついでに判定した結果をカウントしながらテキストログにでも吐き出せば、テスト何件中のうち何件OKで何件NGなのか、といったデータを出すこともできます。

ホワイトボックスの視点からテストを見直す

さて、次に「作ったテストがちゃんとロジックを網羅しているか?」ということを確認します。
「処理がすべて網羅されていることを確認する」ために必要となるのが、「カバレッジ計測」というものです。
では、先ほどと同じ関数をサンプルとします。

■最新のiPhoneの購入・機種変更なら店頭より得で、予約しやすいオンラインショップ。
機種の頭金や使わないオプションパックをつけて年間何万円も損していませんか?
オンラインショップなら故障のサポートもしっかりしていて最低限の費用。待たされることもありません。
 → ドコモオンラインショップ
 → auオンラインショップ
 → ソフトバンクオンラインショップ

最新のiPhoneを得して乗り換えるなら、最大6万円のキャッシュバックがある
→ SMARTPHONE STORE
がお得です。