ユニットテスト

📖 もうちょい詳しく

何が新しいの？

ソフトウェアは小さな部品（関数やモジュール）がたくさん組み合わさってできています。手作業で全体を動かして確認していると、どこが原因で壊れたのか分かりにくく、確認にも時間がかかります。そこで、部品ひとつひとつを自動でたしかめるやり方が広まりました。これがユニットテストです。

どうやって動いてるの？

ユニットテストは「この入力を渡したら、この結果が返ってくるはず」という期待値をコードで書いておきます。テストを実行すると、実際の結果と期待値をプログラムが自動で見くらべます。一致すれば成功、ちがえば失敗と教えてくれます。ひとつの部品だけを切り出して試すので、どこが悪いのかをすぐに特定しやすくなります。

何ができるの？

コードを直したあとにテストをまとめて流せば、思わぬ場所が壊れていないかを一気に確認できます。新しい機能を足したときも、これまで動いていた部分が無事かどうかを自動でチェックできます。手作業の確認を減らし、安心してコードを変えていけるようになります。

🌱 身近なたとえ

工場の検品で例えると分かりやすいです。完成品をまとめて確認するのではなく、ネジ・ばね・歯車といった部品ごとに「この部品は規格どおりか」を先に検査します。部品の段階で不良が見つかれば、組み立てる前に直せます。ユニットテストも同じで、小さな部品の正しさを先にたしかめておく仕組みです。

✅ まず覚えるポイント

• 対象は「部品（関数など）ひとつ」という小さな単位
• 「この入力ならこの結果」という期待値をあらかじめ書く
• 実行すると合っているかを自動で判定してくれる
• 失敗した場所がすぐ分かるので原因をたどりやすい
• コードを直しても壊れていないかを何度でも確認できる

🧭 よくある勘違い

テストを書けばバグはなくなる？

ユニットテストは「書いた範囲」しか確認できません。テストで想定していない使われ方や、部品どうしの組み合わせで起きる不具合は見つけられないことがあります。バグを減らす助けにはなりますが、すべてを防げるわけではありません。

テストを書くのは時間のムダ？

最初はコードが増えて手間に感じます。ただ、後からの手作業の確認や、壊れた箇所さがしにかかる時間を大きく減らせることが多いです。長く使うソフトウェアほど、テストが支えになります。

テストはエンジニアが手で動かすもの？

ユニットテストはプログラムが自動で判定してくれます。人が画面を見て確かめる作業とはちがい、ボタンひとつで何百件も一気に流せるのが特長です。

🧩 関連して覚えると楽な言葉

• テスト駆動開発(test-driven): テストを先に書いてから、それを満たすコードを作る進め方
• CI/CD(ci-cd): コードを変えるたびにテストを自動で流す仕組み
• リファクタリング(refactoring): 動きを変えずにコードを整理すること。テストがあると安心して進められる
• 関数(function): ユニットテストでよく確認する、処理のひとかたまり

🏁 ひとことでまとめ

小さな部品が思ったとおりに動くかを、コードで書いて自動チェックしておく。それがユニットテストです。