テストの検知力を評価するとき、そのアサーションが「利用者から観測可能な振る舞い」を固定しているのか、単に「特定の実装呼び出し」を固定しているだけなのかを切り分ける。内部メソッドを呼んだかどうかを spy で assert するテストは実装詳細に密結合で脆く、リファクタで容易に壊れる一方、実装の正しさは保証しない。狙うべきは画面値・API 応答・出力といった観測可能な挙動の検証である。二つの実装が同じ観測結果を返すなら(例: 対応ロケールに tr/az が無い環境での toLowerCase と toLocaleLowerCase)、その差を狙う検知器は要件が要求しておらず、作っても意味がない。故意ずれ(mutation)を入れてテストが落ちても、落ちる理由がグローバルなプロトタイプ差し替えや spy 由来なら、それは「そのメソッドを呼んでいること」を固定しているだけで、振る舞いの回帰を検知していない。落とし穴: mutation が赤くなったことだけを検知力の証拠にする。正しくは、観測可能な差がある入力でだけ mutation を設計し、テストは観測結果(表示・出力)を assert する。