第87条
ビヨンセ・ルール
共有コードベースでは、どのテストも確かめていない挙動こそが予告なく変わる。
心得
頼っている挙動には、テストを置く
どうするか
共有ライブラリや依存先に頼っている挙動には、すべてテストを書く。そのテストが、他人の変更を止める CI の中で走るようにする。テストで捕まえられずに何かが壊れたら、障害を閉じる前にそのテストを足す。共有コードを持つ側なら、テストが契約だと前もって宣言する。ただし、自分の変更で利用者側のテストを実際に走らせていないなら、このルールを持ち出さない。
なぜ起きるか
コードベース全体が使う基盤を変えるチームは、呼び出し側をすべて読むことはできない。この規模で確かめられる契約は、テストスイートしかない。スイートが確かめていない挙動は変更する側から見えず、予告なく変わる。不注意のせいではなく、それが大事だと知らせるものが何もないからだ。このルールは、その死角を責任の分担に置き換える。無関係な変更が自分たちのテストを全部通ったのに製品に問題が出たなら、修正も、足りなかったテストも自分たちの仕事になる。このルールが公平なのは、誰の変更に対しても全員のテストを走らせる CI が行き渡っている場合に限られる。
当てはまらなくなるとき
チャーンルール：テストの形をした契約は、変更する側に何を壊したかを教えるだけで、壊してよかったことにはならない。変更するチームは、利用者の移行作業をそれでも負う。
出典
Adam Bender「Testing Overview」、Winters, Manshreck & Wright『Software Engineering at Google』(O'Reilly, 2020) 第 11 章。"If you liked it, then you shoulda put a test on it" と、コードベース全体に変更をかける基盤チームがこのルールを使うことの出典。
原典を読む引用するとき
コラムで読む
関連する法則
- 08ハイラムの法則利用者が十分に多ければ、バグも含めた観測可能な挙動すべてに誰かが依存する。
- 88チャーンルール共有基盤を変えるチームが移行作業を利用者に押しつけられると、変更のコストは利用者の数だけ膨らむ。
- 95殺虫剤のパラドックスバグを見つける方法はどれも、その方法では見つからないバグを残す。だから変わらないテストスイートが見つけるバグは減っていく。
- 97ワン・バージョン・ルール共有する依存先のどのバージョンを使うかを利用者が選べると、選ぶたびに、選んでいない誰かが衝突を抱える。
- 105テストオラクル問題テストが誤った答えを捕まえられるのは、コードとは別に正しい答えを知っているものがあるときだけだ。そして多くのプログラムには、それがない。