おれは由緒正しき伝統的なプロジェクトを担当することになったソフトウェア開発者。いつものようにきついスケジュールで仕事をしていると、偉い人から大量の機能追加要請が届いた。機能追加に夢中になっていたおれは、水面下で起こっていた大量のデグレに気づかなかった。おれはその責 任を取られされ、目が冷めたら…再発防止策をこうじるよう命じられていた。
「また不具合を起こしたら、他のメンバーの査定にも危害が及ぶ」
Chat GPT の助言で真面目に再発防止策を考え始めたおれは、偉い人に再発防止策を聞かれ、とっさに「単体テストを導入します」と答えてしまい、急いでコードの調査をはじめた。
ところがこのコード…とんだクソコードでいろいろなコンポーネントが密結合しまくっていて単体テストどころじゃない。みかねたおれはリファクタリングをはじめようとしたが偉い人に「そんな無駄な作業をしてまたデグレ起こしたらどうするつもりなんだ」と舌打ちされる始末。
そんなとき、おれが偶然出会ったのがスナップショットテスト。スナップショットテストとは、プログラムの現在の出力と以前の出力と比較することで予期せぬ変更がないことを確認するテスト手法のことだ。スナップショットテストは、通常のテストとは違っていい感じの入力と期待値を用意する必要がなく、出力さえ取れればテストが書ける。だから、なんだか難しい処理に対しても簡単にテストが書ける。
もちろん最初のスナップショットを作るときそれが正しい出力になっているかどうか確認しないといけないんだけど、どうせいまの出力から結果を変えるわけにもいかないから、おれはいまの出力を期待値として脳死で採用していった。こうしておれは短期間で大量のスナップショットテストを量産していった。
（続く）
という妄想を最近してる。
こうやってデグレへの耐性ができたら、次はリファクタリングして単体テスト書いて…っていうのが理想なんだろうな。でもこういうプロジェクトは最低限度の不具合修正とかするだけのパターンも多いだろうから、その場合は前と変わらないことを保証できるスナップショットテストだけでも十分そう。そういう時はリファクタリングをやる必要はないかもなぁと思ったりもしてる（やりたいけど）。
あと、大量にできたスナップショットを管理しきれるのか、とくに差分が発生したときに原因調査できるのかっていうところはかなり不安要素だと思う。とくに今回のように複雑なものをスナップショットにしている場合はたぶん原因が全然分からなくて、スナップショットだけ常に更新される意味の薄いテストになってしまう危険性はかなりあると思う。だから、たぶんできることならスナップショットテストよりもいわゆる普通のアサーションを書く単体テストのほうがいい。
でも書けないとあきらめるくらいならスナップショットテストを書いたほうが断然マシだとも思う。少なくとも「何かが変わった」ことがわかるだけでもやっぱり全然違う。
おれたちにはまだスナップショットテストがある！