コーディング時の工夫
- AAAパターン（Arrange / Act / Assert）を守る
準備→実行→確認がはっきりして、読みやすいテストになる。 - テスト名は意味を持たせる
メソッド名_条件_期待結果のように書くと失敗時の原因がすぐ分かります。 - インフラ依存は持ち込まない
DBやファイルアクセスはモック化。そうしないとテストが重く、不安定になります。 - テストコードにロジックを書かない
複雑な処理は逆にテストのバグを生みやすい。 - 一つのテストで一つのケースだけを確認する
複数を混ぜると、失敗したときの切り分けが難しくなる。 - 同じ入力なら同じ結果を出すこと
乱数や時刻に依存する処理は制御しておく。 - 後片付きを忘れない
テスト同士の干渉を防ぐため、環境やモックはきちんとリセット。
実行と運用のポイント
- CIと連携させる
コミットごとにテストが走るようにして、早めに不具合を発見。 - スピードを大事にする
遅いテストは回さなくなるので、できるだけ軽く。 - 保守性を意識
コードが変わったらテストも変える。重複や不要なテストは整理。 - 失敗時のログをしっかり残す
入力や実行パスを記録しておけば、原因追跡がスムーズに。 - カバレッジ以外の指標も活用する
欠陥の流入経路、実行時間、失敗率なども見ておくとより実態が分かります。
出典：古賀正雄 エンジニアマインド
注意点
もちろん「単体テストさえやれば安心」というわけではありません。
- カバレッジが高くてもバグは残る
条件の組み合わせや設計上の問題までは拾えないことも。 - やりすぎはコストが増える
改善効果の少ない部分に大量のテストを書くと、保守の負担ばかり増える。 - カバレッジと品質の関係は弱い
研究では、テストカバレッジの高さと実際の品質の相関は低いとされる例もあります。 - AIや確率処理が入ると難易度が上がる
非決定的な挙動をどうテストするかは別の工夫が必要。実際、AI系OSSの多くは単体テストが十分に整っていません。
まとめ
単体テストは「基本だけど奥が深い」工程です。
カバレッジの目標を決める、異常系を入れる、依存を切る、CIとつなぐ…
一つ一つは小さな工夫でも、積み重ねることで安心感が違ってきます。
ただし万能ではありません。
結合テストやレビューと組み合わせてこそ、真の品質保証につながります。
今後の運営の参考にさせていただきまする。