postDevとは
フロントエンド開発テスト最前線
登壇者
株式会社リクルート / 株式会社ニジボックス デベロップメント室室長
Software Engineer
古川 陽介
タワーズ・クエスト株式会社 取締役社長
Programmer / IT consultant
和田 卓人
株式会社リクルート / 株式会社ニジボックス
Software Engineer
倉見 洋輔
テストの歴史
フロントエンドという概念自体もここ10年ぐらいできてきたような気がしている
そもそもフロントエンドテストって、あまりこう書かれてこなかったのかなとかその辺の経緯が私はちょっとなんとなく肌感覚としてある
ロジックの部分では帰ってくるんですけど、見た目のところのテストは少ない
自動テストのテストコードは少ない。コスパが悪くてどんどん治安が悪化していった。目視確認に置き換えられていった
なぜか→頻繁に変更が生じるたびにテストコードが壊れてメンテナンスがかかる。そもそも技術的にも難しい。
テストコードがあると将来の開発における投資ではあるが、現時点で投資効果に見合わない
E2Eテストでは？
フロントのテストは正解を決められない。それなのに壊れやすくてメンテナンスが必要。
コストをかける意味はあるがコストがかけられない
テストを実施できるように画面を30秒スリープする謎の処理を入れていた
フロントエンドにてテストができるようになった背景
フロントエンドとバックエンドが分離されるようになった
それに伴ってフロントエンドでは
サーバーサイドがなくてもDOMが構築できる、
バックエンドがなくてもデータがあればフロントエンドだけで画面が描画できる
アーキテクチャーの勘所（PinchPoint）がわかっていれば、フロンド／バックでマルチで開発できるようになった
ロジックをフロントエンドに搭載することで、フロントエンドでテストをする必要が出てきた
E2Eテストの重要性は下がり、データさえ準備すればテストできるようになった
テストは書いて当たり前の時代へ
PinchPointをJSONで置き換えることで
INが決まればOUTも決まる←テストが一番書きやすいパターン
様々なエンジニアがテストライブラリを作りだした
期待値のHTMLを人が準備していたが、HTML同士でアサートすることが難しい
スナップショットしたHTMLを実行時にアサートする手法が誕生した→スナップショットテスト
ファントムjsではflexboxが描画できなかった
ブラウザのレンダリングエンジンの中のコンポーネントをpackage.jsonに含めることができるようになり
ブラウザ依存によるアサートの精度も向上した
フロントエンドテストを支えるツール
データをINとしてhtmlをOUTとするには？
MSW－Mock Service Worker
MSWをPinchPointに入れてhttp通信をhackした状態で実働に近い形でテストができる
HTTPステータスコードのアサートもできる
ツールの目的はフロント／バックの両方でスキーマを真ん中において開発できることを目的とすること
本番とテストで構成を変えずに利用できるもの、CI/CDができること
本物とモックとの違いにどれだけ早く気付けるかが大事
どんなテストをしているのか
StoryBook
graphql
スキーマ部分にgraphqlを使うと型が決まるので、型が異なることに早く気付ける
フロントエンドテストの今後について
再現できるテストが増えてきたが、不安定要素もまだある
フレイキーテスト
- プロダクトコードの変更
テストが壊れるから変更を懸念することはあってはならない。
そのためにアクセシビリティがあるかん
アクセシビリティが高い画面はテストが壊れにくい→テスタビリティも向上する
メンテナンス性を上げることでアクセシビリティも向上する
テストを導入することでフロントエンドのコードにアクセシビリティが必要となった
エンジニアの気付きが生まれた。品質向上のためのトップダウンが開発生産性としてボトムアップにも発生した。
最後に
フロントエンドテストのよもやまトーク
ありがとうございました