変更履歴
- 2018/6/1 jest@23について追記
はじめに
- 勉強会で使ったスライドをそのまま公開したものです
- TDDとかする時にスナップショットテストするといいよ、という話
前置き
ユニットテスト書いてますか？
- TDDで常にメンテ
- 危なそうなとこだけ書く
- 男は黙って手動テスト
テストコードはコストが高い？
-
テストコードを書く工数が確保できない
->
-
テストコードのメンテが面倒
->
テストコードはコストが高い？
-
テストコードを書く工数が確保できない
-> テストフェーズの工数を前借りする
-
テストコードのメンテが面倒
-> メンテを普段の開発フローに組み込む
（テストコード実装 + テスト実行時間） < （コンパイル/起動時間 + 手動テストの工数）のとき、テストコードを書いた方が生産性が高い
+テストコードがあるとCIでリグレッションテストとして使える
TDD
- テスト駆動開発
- 失敗するテストを書く
- できる限り早く、テストに通るような最小限のコードを書く -> 動くクソコードを書く
- リファクタリングする -> 動く綺麗なコードにする
テストケースの修正、特に期待値の修正が大変
本題
スナップショットテスト
- 最初のテスト実行時にテストケースのアウトプットが保存（スナップショット）される
- スナップショットを目視で確認して期待通りならOK
- 2回目以降はアウトプットとスナップショットを比較して一致していればOK
- スナップショットファイルをgit管理する
テストフレームワーク
- JavaScript, TypeScript
- Jest
- facebook製
- Reactと特に相性がいい
- expect(output).toMatchSnapshot()
- Jest
- PHP
- Python
- etc...
なければ作る
- スナップショットアサーションの中身
- スナップショットファイルを探しに行く。
- if 上書きフラグあり or スナップショットがない
- アウトプットをシリアライズしてスナップショットファイル作成/上書き
- else
- アウトプットをシリアライズしてスナップショットと比較する
スナップショットテストを行うようになって
- ロジックに集中できるようになった
- ロジックを変えた時にテスト結果でスナップショットとのDiffが出るから期待値の確認が楽
- テストコードに時間かけてないからポイ捨てが簡単（もったいないからという理由で動かない/使わないテストが残されている場合がある）
運用時に気をつけるべき点
-
スナップショットファイルの受け入れは期待値が明確になってから行う（当たり前）
-> 間違った期待値をスナップショットにしてしまいがち
-
テスト実行タイミングに依存する値を含めてはいけない
-> 全く同じプロパティ・値を比較しているため
-> 可変値は普通のアサーションで評価する2018/6/1追記 jest@23について
jestの場合、v23でスナップショットの内一部のみ型一致を評価するように指定できるようになったみたいなので別のアサーションを組み合わせる必要がなくなりました。
Snapshot Property Matchers -
スナップショットの更新は1ファイルずつ行う
-> 意図しない更新で間違った期待値になってしまう場合がある
サンプルっぽいもの
-
https://github.com/kentt8046/snapshot-testing-sample
- NodeJS + TypeScript + Jest