【2026年最新】単体テストで何を書けばよいか｜対象の選び方7項目

テストを書こうとして、何から手をつければよいか分からなくなることがあります。すべてを網羅しようとすると終わらず、書かないままだと変更が怖くなります。この記事では、対象の選び方と書き方の順序を整理します。

優先して書く7項目

【結論】壊れたときの影響で決めます。

1. 分岐が多い処理

条件によって結果が変わる箇所は、見落としが起きやすい場所です。

2. 金額や数量の計算

誤りが直接の損害につながります。端数の扱いを含めて確認してください。

3. 過去に不具合が出た箇所

再発を防ぐため、その条件を再現するテストを残します。

4. 境界の値

0、1、上限、下限といった値で挙動が変わることがあります。

5. 外部から受け取る値の検証

想定外の入力に対して、どう振る舞うかを確認します。

6. 変更の頻度が高い場所

よく手が入る箇所ほど、壊れる機会が多くなります。

7. 説明が難しい処理

複雑な処理は、テストが仕様の説明を兼ねます。

対象	優先度	理由
金額の計算	高い	損害に直結する
分岐が多い処理	高い	見落としやすい
過去の不具合箇所	高い	再発を防ぐ
単純な取得や代入	低い	壊れにくい
外部への通信そのもの	別枠	結合の範囲

書かなくてよいもの

【結論】壊れにくい処理は後回しです。

取得や代入だけの処理

値を返すだけの処理にテストを書いても、得られる安心は小さくなります。

言語や標準機能の動作

言語そのものの挙動を確認するテストは不要です。

外部サービスそのもの

相手の動作を確かめるのは単体テストの範囲ではありません。

画面の見た目

配置や色の確認は別の手段が向いています。

1つのテストの構成

【結論】3段に分けて書きます。

準備

必要なデータや状態をそろえます。ここが長いなら、対象の設計に問題がある可能性があります。

実行

確認したい処理を1回だけ呼び出します。

検証

結果が期待どおりかを確かめます。1つのテストで確認する内容は1つに絞ってください。

名前の付け方

何を確認しているかが読めば分かる名前にします。失敗したときに原因を推測しやすくなります。

境界の値を考える

【結論】端で挙動が変わります。

0と1

件数が0のとき、1のときで処理が分かれることがあります。

上限と下限

ちょうどの値と、その1つ外側を確認します。

空の値

空文字や空の一覧を渡したときの挙動を確かめてください。

値がない場合

値が存在しない状態を渡すと、想定外の停止が起きることがあります。

失敗する場合も書く

【結論】正常系だけでは足りません。

誤った入力

想定外の値を渡したときに、適切に拒否されるかを確認します。

例外の発生

想定した例外が投げられるかを確かめます。

メッセージの内容

利用者に返る文言も確認の対象になります。

復帰の動作

失敗した後、状態が壊れずに残っているかを確認してください。

テストが書きにくいとき

【結論】設計の問題であることが多くあります。

準備が長い

1つの処理が多くのものに依存しています。分割を検討してください。

時刻に依存する

現在時刻を直接取得していると、結果が日によって変わります。外から渡す形にすると安定します。

外部との通信がある

通信部分を切り離すと、単体で確認できるようになります。

状態を持ちすぎている

内部の状態が多いほど、確認すべき組み合わせが増えます。

網羅率との付き合い方

【結論】目標にはしないでください。

数値の意味

実行された行の割合を示すだけです。正しさを保証するものではありません。

目標にした場合

数値を上げるためだけのテストが増えます。保守の負担になります。

使い道

まったく触れられていない箇所を見つける道具としては役立ちます。

判断の基準

数値ではなく、壊れたときに気づけるかで判断してください。

継続して回す

【結論】自動で走らないと形骸化します。

実行の自動化

変更のたびに自動で走る仕組みを用意してください。手動では回されなくなります。

実行時間

時間がかかると回されなくなります。遅いテストは別に分けてください。

失敗の放置

赤いまま放置されると、誰も見なくなります。すぐ直すか、原因を記録してください。

不安定なテスト

時々失敗するテストは信頼を失わせます。原因を取り除いてください。

書く順番

先にテストを書いてから実装する進め方もあります。仕様が固まっている処理では、確認したい内容が明確になるため書きやすくなります。

よくある質問（FAQ）

Q1. 何から書けばよいですか

壊れたら困る場所からです。金額の計算や分岐の多い処理が該当します。

Q2. すべてに書くべきですか

不要です。取得や代入だけの処理は後回しで構いません。

Q3. 網羅率はどのくらい必要ですか

目標にしないでください。数値のためのテストは保守の負担になります。

Q4. テストが書きにくいのですが

設計の問題である場合が多くあります。依存を減らすと書きやすくなります。

Q5. 1つのテストで何を確認しますか

1つに絞ってください。複数を混ぜると、失敗の原因が分かりにくくなります。

Q6. 時々失敗するテストがあります

原因を取り除いてください。放置すると全体が信頼されなくなります。

まとめ

単体テストは、壊れたら困る場所から書いてください。分岐が多い処理、金額や数量の計算、過去に不具合が出た箇所が優先されます。

取得や代入だけの単純な処理は後回しで構いません。すべてを網羅しようとすると終わらず、意味の薄いテストが増えます。

境界の値を意識してください。0、1、上限、下限、空の値といった端で挙動が変わることがあります。正常な入力だけでなく、誤った入力を渡したときの動作も確認します。

網羅率は目標にしないでください。実行された行の割合を示すだけで、正しさを保証するものではありません。判断の基準は、壊れたときに気づけるかどうかです。そのためには、変更のたびに自動で走る仕組みが必要になります。

📱 運営の裏側・最新情報はXで発信中 → @ore_chusotsu