テスト
変更しても壊れていないことを確かめる仕組み。
テストの目的は「バグを見つける」より **「安心して変更できるようにする」**ことにある。 テストが無いコードは、怖くて直せなくなる。
種類#
| 種類 | 対象 | 速度 | 数 |
|---|---|---|---|
| 単体 | 関数・クラス | ミリ秒 | 多い |
| 統合 | モジュール間、DB 接続 | 秒 | 中 |
| E2E | 利用者の操作全体 | 分 | 少ない |
テストピラミッド — 下ほど多く、上ほど少なく。 E2E は現実に近いが、遅く、壊れやすい（flaky）。
良いテストの条件#
| 条件 | 内容 |
|---|---|
| 速い | 遅いと実行されなくなる |
| 独立 | 順序に依存しない |
| 決定的 | 毎回同じ結果。時刻・乱数・ネットワークを排除する |
| 意図が読める | 失敗の原因が分かる名前 |
flaky なテストは無いより悪い。 失敗を無視する習慣がつき、本物の失敗も見逃す。
何をテストするか#
- 分岐の多いロジック
- 境界条件（0、空、最大値）
- 一度壊れたところ（回帰テスト）
- 外部との境界（パース、変換）
逆に、単純な getter や UI の細部をテストしても得るものが少ない。
テストしやすさは設計に現れる#
テストが書きにくいコードは、 たいてい依存が多すぎるか、責務が混ざっている。
テストのために設計が改善されるのが テスト駆動開発の主張の中核。
このノート群でも、 CI で リンク検証と単体テストを回すことで、 出典の実在と内部リンクの整合を機械的に保証している。
参考文献#
- Kent Beck. Test-Driven Development: By Example. Addison-Wesley, 2002.
- Martin Fowler. TestPyramid. https://martinfowler.com/bliki/TestPyramid.html
- Michael Feathers. Working Effectively with Legacy Code. Prentice Hall, 2004.