下書きにずっと残ってたので供養。本当は色々書くつもりだったけど量的にも内容的にも一生まとまりそうになかったから自分の主張分だけ少し体裁を整えて出すことにした。
実装の詳細のテストは書いてもいい
ただし成果物をコミットするまでには消しておいた方がいい。
テストの目的や内容によって寿命が異なることをを意識しよう
- 寿命が短い
- 実装している自分のためのテスト
- 意図通りに動いている?
- 自分の実装に自信を持つためのテスト
- 確認が取れ次第寿命を迎える
- 実装している自分のためのテスト
- 寿命が (比較的) 長い
- 機能単位の振る舞い (仕様) に関して記述されたテスト
- 要求に対してこの機能が達成したいことを伝える
- よりユーザとの距離が近いものほど寿命が長くなることが期待できそう
- e.g.) モジュール > クラス > 関数
- 逆にユーザに近いもののテストが壊れやすかったら詳細のテストが紛れているサインかも
- 単に仕様が生煮えなだけかもしれない
- 仕様が変わった、機能がいらなくなったら寿命を迎える
- 機能単位の振る舞い (仕様) に関して記述されたテスト
寿命に応じて適宜テストを削除しよう
残されたテストはそれに意図があると受け取られて消されにくい。そしてその後の実装や開発活動に影響を与える、場合によっては無意味な足枷になりうる (関連: "テストコードの慣性の力")。
Memo: 「テストコードを書くと慣性の力が働く」の元と思われるのは『テスト駆動開発』第III部 第25章 テスト駆動開発のパターン の "TODOリスト" (「... まず、既に書かれているテストというものはすべて、リファクタリングの際にはある種の慣性を伴う。...」)https://t.co/G7n9EL8JxX
— nash (@nashcft) 2020年11月27日
既に書いた、もしくはこれから書くテストの目的から寿命を把握して、寿命を迎えたらきちんと消してあげる。テストが書かれてから消えるまでの過程がコミットログに残る形である必要はない。