単体テスト・品質を保ち作業効率を上げる

この記事を書いたチーム：frontier

単体テストの目的

単体テストは、アプリケーション内の最小単位(メソッドやクラス)を検証するテストです。
大きく分けると主に以下のような目的があります
　・ロジックの正当性の検証(仕様通りか)
　・リグレッション防止(既存機能の破壊を防ぐ)
　・リファクタリングの安心材料
　・ドキュメント代わりになる

１．自己完結
　・依存先(DB、API、ファイルシステム)に依存しない事
　・モック/スタブを活用して外部影響を排除

２．意図を明確に
　・入力、処理、期待結果を明示的に記述
　・テスト名や関数名も「～すべき」「～であること」のように読みやすく

・完全網羅できることが理想ですが、現実的には重要ロジック・分岐に焦点を絞る
・コーナーケース(null、空文字、上限/下限)なども忘れずに行う

１．テスト対象の設計を意識する(テストしやすいコードを書く)
　・単一責任の関数に分ける(SRP原則)
　・依存性注入(DI)を活用してテストしやすい構造に
　・非同期・副作用のある処理は分離する

２．テストコードをＤＲＹに保つ
　・テストデータの共通化(Factory、Builderパターン)
　・テストセットアップの整理([TestInitialize]、SetUp())

３．モックを賢く使う
　・MoqやNSubstituteを使って、依存するサービスを仮装
　・過度なモック地獄に陥らないように注意(テスト対象が小さく分かれていることが前提)

４．カバレッジより「意図を持ったテスト」
　・カバレッジ100%を盲目的に目指すのではなく、失敗しそうな箇所・重要な分岐を優先

５．CIで自動実行＋失敗時は即通知
　・GitHub Actions / Azure DevOps / GitLab CIなどで、テストは毎回自動実行
　・失敗時はSlackやTeamsに通知すれば早期対処が可能に

アンチパターン	解説
テストが外部サービスに依存	テストが不安定になりCIが失敗しがちに
複数条件を1つのテストで	テスト失敗時にどの条件が原因か特定しづらい
テストが長すぎる	保守性が下がり、新しい開発者が理解できなくなる
無意味なアサート	Assert.AreEqual(true, true); などは意味がない
テストデータがハードコードされている	入力値変更が面倒、流用が効かない