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

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

Transcript

1. レガシーでウォーターフォールな

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

   View Slide

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

   View Slide

3. 3
   今日話すこと
   

   View Slide

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

   View Slide

5. View Slide

6. View Slide

7. 元々は独自フレームワークだった
   ▸ jQuery製で、2014年末頃にfirst commit
   ▸ BabelifyでES2015にトランスパイル、

   MorphDOMで差分レンダリングを実現
   ▸ TemplateにModelを渡すとレンダリングし、 

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

   View Slide

8. 入力値を表示する場合
   8
   

   View Slide

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

   View Slide

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
    案件開発をしながら、
    二年かけて小さくリファクタリング
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

14. 手戻りや結合バグを減らすには
    ▸ コンポーネント単位のテストだけでは、

    実際のユースケースを確認できず不十分なことが多い
    ▸ バグの原因を辿ると要件定義漏れだったということも多く、

    そもそもステークホルダーと要件を握りきれていなかったことも
    ▸ 最終成果物が不明瞭なので、

    何を作ればいいのか何を作ってはいけないのかもわからない
    14
    これから作るものについての
    合意形成がかなり重要
    

    View Slide

15. 15
    vue-testing-
    library
    

    View Slide

16. vue-testing-libraryとは
    ▸ dom-testing-libraryのVue用軽量アダプター
    ▸ Vueコンポーネントの実装に依存せず、

    レンダリングされる実際のDOMノードを使ってテストを行う
    ▸ OSやブラウザ環境をブラックボックスにし、

    実際のユーザー操作をシミュレートするテストを書くことができる

    16
    コンポーネント同士が結合された状態で
    より現実に近いテストを実施できる
    

    View Slide

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

    View Slide

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

    View Slide

19. vue-testing-libraryの導入で良かったこと
    ▸ 要件を固めてから開発を進めるプロジェクトと相性が良かった
    ▸ これから作るものが明確になり、

    開発工程でのQ&Aや手戻りを少なくすることができた
    ▸ 結合工程以降で検知されるバグ内容をOSやブラウザなどの

    環境依存やデータパターンによるものに限定することができた
    19
    ToDoリストのようなテストケースがあることで

    全体像の把握が容易になった
    

    View Slide

20. vue-testing-libraryの導入で難しかったこと
    ▸ テストケースの粒度の設定が難しい
    ▸ Mock/Stub/Spyを多用すると、テストコードの作成とメンテにコストがかか
    る上に、プロダクションコード実行時の状況とかけ離れてしまう場合がある
    ▸ テストコードを書く部分は自分たちが実装した部分だけ、

    フレームワークやブラウザの処理までテストするテストコードは書かない
    20
    単体テストと結合テストの
    バランス調整が難しい
    

    View Slide

21. 21
    まとめ
    

    View Slide

22. まとめ
    実コンポーネントに依存するテストは腐りやすい。

    vue-testing-libraryを使うと、

    コンポーネントが結合された実態に近い状態で

    機能をテストすることができる。

    単体テストでは拾えない結合バグや、

    要件定義漏れによる手戻りの防止には、

    製造する前のテストケース作成がオススメ。
    22
    

    View Slide

23. 23
    EOF
    

    View Slide