レガシーでウォーターフォールなVue.jsでの大規模開発に捧げるテスト駆動フロントエンド開発の話 / v-tokyo10

by Yuji Yamaguchi

Slide 1

Slide 1 text

レガシーでウォーターフォールな  Vue.jsでの大規模開発に捧げるテスト駆動フロントエンド開発の話 2019/07/25 Vue.js v-tokyo Meetup #10 Yuji Yamaguchi

Slide 2

Slide 2 text

自己紹介 2 ▸ 名前 ▸ ヤマグチユウジ ▸ 職種 ▸ フロントエンドエンジニア ▸ 経歴 ▸ 2011年04月通信系企業 ▸ IoTやWebコンテンツサービスの開発運用 ▸ 2016年01月ネット広告系企業 ▸ 広告配信管理システムの開発運用 ▸ 2016年10月株式会社リクルートライフスタイル ▸ 飲食店向け予約台帳システムの開発

Slide 3

Slide 3 text

3 今日話すこと

Slide 4

Slide 4 text

飲食店向け予約台帳アプリ：レストランボード 4

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

元々は独自フレームワークだった ▸ jQuery製で、2014年末頃にfirst commit ▸ BabelifyでES2015にトランスパイル、  MorphDOMで差分レンダリングを実現 ▸ TemplateにModelを渡すとレンダリングし、   SelectorとFunctionを渡すとバインドするMVVMフレームワーク 7 Reactなどが話題になり始めた頃なので実は少し影響を受けている

Slide 8

Slide 8 text

入力値を表示する場合 8

Slide 9

Slide 9 text

9 完成度は高いが今後の継続性は

Slide 10

Slide 10 text

Vue.js導入はまずは足元を整えてから 10 2014/12 2016/10 2017/10 2018/10 2015/4 独自FW誕生レストランボード  開発開始脱Browserify 脱Grunt ESLint Jest Prettier Promise Vue.js async / await 案件開発をしながら、二年かけて小さくリファクタリング

Slide 11

Slide 11 text

Vue.js導入時に心掛けたこと ▸ 小さく移行する ▸ Drasticに変えない ▸ 画面毎や部品毎、MoleculesやAtomsから導入 ▸ 案件で触る部分だけ、リファクタリングの粒度にとどめる ▸ レガシーコードのロジックは資産、できるだけそのまま使う 11 導入による大きなインシデントはなし！

Slide 12

Slide 12 text

現状の導入比率 12 45% 55% 62画面中34画面で導入済み

Slide 13

Slide 13 text

13 単体テストは完璧なのに手戻りや結合バグが多くなりがち

Slide 14

Slide 14 text

手戻りや結合バグを減らすには ▸ コンポーネント単位のテストだけでは、  実際のユースケースを確認できず不十分なことが多い ▸ バグの原因を辿ると要件定義漏れだったということも多く、  そもそもステークホルダーと要件を握りきれていなかったことも ▸ 最終成果物が不明瞭なので、  何を作ればいいのか何を作ってはいけないのかもわからない 14 これから作るものについての合意形成がかなり重要

Slide 15

Slide 15 text

15 vue-testing- library

Slide 16

Slide 16 text

vue-testing-libraryとは ▸ dom-testing-libraryのVue用軽量アダプター ▸ Vueコンポーネントの実装に依存せず、  レンダリングされる実際のDOMノードを使ってテストを行う ▸ OSやブラウザ環境をブラックボックスにし、  実際のユーザー操作をシミュレートするテストを書くことができる  16 コンポーネント同士が結合された状態でより現実に近いテストを実施できる

Slide 17

Slide 17 text

カウンターアプリで考える 17

Slide 18

Slide 18 text

結合テストファースト 18 成果物イメージの合意形成のためにテストケースの作成から始める

Slide 19

Slide 19 text

vue-testing-libraryの導入で良かったこと ▸ 要件を固めてから開発を進めるプロジェクトと相性が良かった ▸ これから作るものが明確になり、  開発工程でのQ&Aや手戻りを少なくすることができた ▸ 結合工程以降で検知されるバグ内容をOSやブラウザなどの  環境依存やデータパターンによるものに限定することができた 19 ToDoリストのようなテストケースがあることで  全体像の把握が容易になった

Slide 20

Slide 20 text

vue-testing-libraryの導入で難しかったこと ▸ テストケースの粒度の設定が難しい ▸ Mock/Stub/Spyを多用すると、テストコードの作成とメンテにコストがかかる上に、プロダクションコード実行時の状況とかけ離れてしまう場合がある ▸ テストコードを書く部分は自分たちが実装した部分だけ、  フレームワークやブラウザの処理までテストするテストコードは書かない 20 単体テストと結合テストのバランス調整が難しい

Slide 21

Slide 21 text

21 まとめ

Slide 22

Slide 22 text

まとめ実コンポーネントに依存するテストは腐りやすい。  vue-testing-libraryを使うと、  コンポーネントが結合された実態に近い状態で  機能をテストすることができる。  単体テストでは拾えない結合バグや、  要件定義漏れによる手戻りの防止には、  製造する前のテストケース作成がオススメ。 22

Slide 23

Slide 23 text

23 EOF