単体テストが分からない人へ
エンジニアになってから1年間運用保守に携わっていて、設計やSTに携わっていたので、実装、単体テストの経験がありませんでした。
研修などで知識としては頭にあったものの、実際に作業を始めると分からないことだらけで、知識と実際の作業が全く紐づかない状況で、とても大変な思いをしたので、備忘録として残します。
同じような境遇の方の力になればと思います。
単体テストが分からない理由
単体テストが分からない理由は
私の場合、
テストの全体像が把握できていないことでした。
単体テストと聞いて、頭の中にある「ホワイトボックステスト」や「制御フローテスト」などイメージはありましたが、その単語と実際の目の前にあるコードをどう紐づけて、そしてどうテストケースを洗い出せばよいのかがわかりませんでした。
そうしたミクロの視点から初めてしまうと、軸が定まっていないため「テストケースが漏れている」や「観点が違う」との指摘をもらってばかりでした。
そこで一度立ち止まり、マクロの視点から考えなおすことにしました。
単体テストの立ち位置は？
そもそも単体テストとは
ウォーターフォールの工程でいえば、コーディング後の工程で結合テストの前の工程です。
(https://webrage.jp/techblog/v_shaped_mode/ より引用)
V字モデルでは、一番大きな要求分析から始め、要件定義、基本設計と、作業がより具体的かつ小さな単位になっていきます。
そしてコーディングが最小単位で、その後、単体テスト、結合テストを経て、一番大きな受け入れテストに進んでいきます。
この時イメージしてほしいのは、各工程における成果物の量です。
要求分析は、せいぜい、顧客とのやり取りに使う数ファイルが成果物となると思います。
そして進んで基本設計はその機能分の成果物になり、詳細設計ではより細かい単位で十数ファイルほどに分割されていくと思います。
その後テスト工程になると、その逆で、成果物が多い工程から徐々に少なくなっていくものです。
Ｖ字モデルについて
コーディングと単体テストは全くの別物なので違いはあきらかですが、私は単体テストと結合テストの違いをあまり理解できていなかったので、まとめます。
単体テストと結合テストはそれぞれの役割が異なります。
・単体テスト：最小単位の機能ごとに正しく動作することを確認する
・結合テスト：複数の機能が相互的に作用し、正しく動作していることを確認する
具体的な例を挙げると
例えば、入力欄にユーザーの名前を入力し、生年月日を得るシステムがあったとして
内部構造はA→B→Cとような処理構造になっています。
そのシステムのテストを考えると
単体テストは
Aが正しく動作すること
Bが正しく動作すること
Cが正しく動作すること
結合テストは
A→B→Cの全体が正しく動作すること
がそれぞれ目的です。（あくまでイメージ）
ここで先ほどの成果物の量を思い出してほしいのですが、単体テストの方が成果物の量が多くなりそうですよね。
なぜならより細かい単位で確認を行うからです。
そして、結合テストは単体テストでそれぞれの機能（ABC）が正しく動いていることを前提にテストをします。
これで、単体テストと結合テストの違いが分かったかと思います。
最後に
テストの目的は2つあると考えています。
1つ目は「V字モデルの構成で対になる設計書に記載されている仕様通りの実装となっていることを確認する」
2つ目は
「受動的な作業ではなく、バグを見つける能動的な仕事」
この2つを忘れないように、今後もテストを実施していきたいです。
随時更新予定です。
誤りなどありましたらコメントによろしくお願いいたします。