Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

大規模ウォーターフォール開発の中で実施している、vue-testing-libraryを利用したテスト駆動開発の紹介です。

399e7330fa2a9ed06cbe81308ba8db6e?s=128

Yuji Yamaguchi

July 25, 2019
Tweet

Transcript

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

    Yamaguchi
  2. 自己紹介 2 ▸ 名前 ▸ ヤマグチ ユウジ ▸ 職種 ▸

    フロントエンドエンジニア ▸ 経歴 ▸ 2011年04月 通信系企業 ▸ IoTやWebコンテンツサービスの開発運用 ▸ 2016年01月 ネット広告系企業 ▸ 広告配信管理システムの開発運用 ▸ 2016年10月 株式会社リクルートライフスタイル ▸ 飲食店向け予約台帳システムの開発
  3. 3 今日話すこと

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

  5. None
  6. None
  7. 元々は独自フレームワークだった ▸ jQuery製で、2014年末頃にfirst commit ▸ BabelifyでES2015にトランスパイル、
 MorphDOMで差分レンダリングを実現 ▸ TemplateにModelを渡すとレンダリングし、 


    SelectorとFunctionを渡すとバインドするMVVMフレームワーク 7 Reactなどが話題になり始めた頃なので 実は少し影響を受けている
  8. 入力値を表示する場合 8

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

  10. Vue.js導入はまずは足元を整えてから 10 2014/12 2016/10 2017/10 2018/10 2015/4 独自FW誕生 レストランボード
 開発開始

    脱Browserify 脱Grunt ESLint Jest Prettier Promise Vue.js async / await 案件開発をしながら、 二年かけて小さくリファクタリング
  11. Vue.js導入時に心掛けたこと ▸ 小さく移行する ▸ Drasticに変えない ▸ 画面毎や部品毎、MoleculesやAtomsから導入 ▸ 案件で触る部分だけ、リファクタリングの粒度にとどめる ▸

    レガシーコードのロジックは資産、できるだけそのまま使う 11 導入による大きなインシデントはなし!
  12. 現状の導入比率 12 45% 55% 62画面中34画面で導入済み

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

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

    14 これから作るものについての 合意形成がかなり重要
  15. 15 vue-testing- library

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

    コンポーネント同士が結合された状態で より現実に近いテストを実施できる
  17. カウンターアプリで考える 17

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

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

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

    単体テストと結合テストの バランス調整が難しい
  21. 21 まとめ

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

  23. 23 EOF