結局 View のテストはどうすればいいのか？
Meguro.es #15 @ Drecom
@ktsn
View のテストと言えば
ロジックや状態はコンポーネントの外に
出してそっちをテストしてます
View のテストはコストが大きいので
やってないです
UI はテストを書いても変更が発生しやすくて無駄になりがちなので……
とは言っても……
- コンポーネントの内部に状態やロジックを
持たせたいケースもある - View のテストが 0 だと変更がこわすぎる
カレンダーを例に考える
どういうテストをするか
- Snapshot テスト
- ある状態の HTML やスクショ画像を比較
- 考えることが少ないので楽
- 意図しない差分で落ちるのはつらそう
- 普通に DOM やコンポーネントの状態をアサーション
- DOM の構造が変わると終了する
- E2E でやるとすごくつらそう
- ユニットテストならありな印象
今回はこっちの話をします
テストを書くべきなのは
どこなのかを考える
- 何か変更をおこなった後に確認がめんどくさそうな
場所は書きたい- 全部めんどくさいけど比較的面倒なものを選ぶ
- View の振る舞いとしてクリティカルな部分は書きたい
- テストを書くのがつらい部分は書きたくない
一時的な値を保持するケース
ユーザーに見えない振る舞い
アニメーション…… (無理)
つらい部分を切り離す
🤔
$('[data-value=2018-06-05]').click()つらい部分を切り離す
😎
find(DateCalendar)
.emit('select', new Date('2018/06/05'))まとめ
- 自分が手作業で確認したくない部分はどこかを考える
- その中でテストコードを書いたり保守するつらさと
手作業のコストを比較して、ペイするものは書く- ↑これを考えるのが一番むずい
- つらさを軽減するためにコンポーネントを分けるのも良い