Share
Embed
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