大規模ウォーターフォール開発の中で実施している、vue-testing-libraryを利用したテスト駆動開発の紹介です。
レガシーでウォーターフォールな Vue.jsでの大規模開発に捧げるテスト駆動フロントエンド開発の話2019/07/25Vue.js v-tokyo Meetup #10Yuji Yamaguchi
View Slide
自己紹介2▸ 名前▸ ヤマグチ ユウジ▸ 職種▸ フロントエンドエンジニア▸ 経歴▸ 2011年04月 通信系企業▸ IoTやWebコンテンツサービスの開発運用▸ 2016年01月 ネット広告系企業▸ 広告配信管理システムの開発運用▸ 2016年10月 株式会社リクルートライフスタイル▸ 飲食店向け予約台帳システムの開発
3今日話すこと
飲食店向け予約台帳アプリ:レストランボード4
元々は独自フレームワークだった▸ jQuery製で、2014年末頃にfirst commit▸ BabelifyでES2015にトランスパイル、 MorphDOMで差分レンダリングを実現▸ TemplateにModelを渡すとレンダリングし、 SelectorとFunctionを渡すとバインドするMVVMフレームワーク7Reactなどが話題になり始めた頃なので実は少し影響を受けている
入力値を表示する場合8
9完成度は高いが今後の継続性は
Vue.js導入はまずは足元を整えてから102014/12 2016/10 2017/10 2018/102015/4独自FW誕生レストランボード 開発開始 脱Browserify脱GruntESLintJestPrettierPromiseVue.jsasync / await案件開発をしながら、二年かけて小さくリファクタリング
Vue.js導入時に心掛けたこと▸ 小さく移行する▸ Drasticに変えない▸ 画面毎や部品毎、MoleculesやAtomsから導入▸ 案件で触る部分だけ、リファクタリングの粒度にとどめる▸ レガシーコードのロジックは資産、できるだけそのまま使う11導入による大きなインシデントはなし!
現状の導入比率1245% 55%62画面中34画面で導入済み
13単体テストは完璧なのに手戻りや結合バグが多くなりがち
手戻りや結合バグを減らすには▸ コンポーネント単位のテストだけでは、 実際のユースケースを確認できず不十分なことが多い▸ バグの原因を辿ると要件定義漏れだったということも多く、 そもそもステークホルダーと要件を握りきれていなかったことも▸ 最終成果物が不明瞭なので、 何を作ればいいのか何を作ってはいけないのかもわからない14これから作るものについての合意形成がかなり重要
15vue-testing-library
vue-testing-libraryとは▸ dom-testing-libraryのVue用軽量アダプター▸ Vueコンポーネントの実装に依存せず、 レンダリングされる実際のDOMノードを使ってテストを行う▸ OSやブラウザ環境をブラックボックスにし、 実際のユーザー操作をシミュレートするテストを書くことができる 16コンポーネント同士が結合された状態でより現実に近いテストを実施できる
カウンターアプリで考える17
結合テストファースト18成果物イメージの合意形成のためにテストケースの作成から始める
vue-testing-libraryの導入で良かったこと▸ 要件を固めてから開発を進めるプロジェクトと相性が良かった▸ これから作るものが明確になり、 開発工程でのQ&Aや手戻りを少なくすることができた▸ 結合工程以降で検知されるバグ内容をOSやブラウザなどの 環境依存やデータパターンによるものに限定することができた19ToDoリストのようなテストケースがあることで 全体像の把握が容易になった
vue-testing-libraryの導入で難しかったこと▸ テストケースの粒度の設定が難しい▸ Mock/Stub/Spyを多用すると、テストコードの作成とメンテにコストがかかる上に、プロダクションコード実行時の状況とかけ離れてしまう場合がある▸ テストコードを書く部分は自分たちが実装した部分だけ、 フレームワークやブラウザの処理までテストするテストコードは書かない20単体テストと結合テストのバランス調整が難しい
21まとめ
まとめ実コンポーネントに依存するテストは腐りやすい。 vue-testing-libraryを使うと、 コンポーネントが結合された実態に近い状態で 機能をテストすることができる。 単体テストでは拾えない結合バグや、 要件定義漏れによる手戻りの防止には、 製造する前のテストケース作成がオススメ。22
23EOF