前提として
- Viewは状態の写像であるということがわかってきていて、状態さえ与えればViewの状態が再現される
- どういう操作をすると、どの状態にたどり着くか、はアプリケーションのドメインの知識としてテストすればよい
- ところでViewをTDDで書いていく人はあんまりいなくて、試行錯誤しながら作っていく人が多いのでは
ということをふまえると、スナップショットのうれしさは
- ああしてこうして、という準備を経ずに状態ごとのテストを書ける
- 状態の写像である世界観と相性が良い
- サーバーサイドでこのようなデータをストレージに入れて…月をまたいだらこの操作をして…みたいなデータをセットアップしていくという考えからは切り離せる
- 実装が完成した段階で、これを正とする、と表明する流れで書けるので、アサーションを手書きしなくてよい
- この状態のときのViewはこうです、と言ってしまえば以降それがテストとして動く
- TDDしなくても、できたときに、これが仕様です、と言えるのでTDDと相性悪い箇所と相性が良い
- アサーション手書きと比べると結果の完全な一致を要求するので、ちょっとした変化もテストを落としてくれる
- 人間の解釈、みたいな話しではなくて、一致するかどうか、ということだけ考えれば良くて、アウトプットが変わるならテストを書き換えるしかない
というあたり、という理解をしていました。
BackstopJSでやっているようなビジュアルリグレッションテストも世界観としては近そう。
ただし、ビジュアルリグレッションテストの場合はビジュアルが揃っていればいいので、ページ全体が巨大なペライチの画像になっていてもテストは通ってしまう。
偶然みかけたのでちょっと書いてみた。
かれこれ1年くらい何故スナップショットテストをするのか理由を探しているけど未だにこれといった理由を見つけられていない
— mizdra (@mizdra) 2020年10月6日