Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
レガシーでウォーターフォールなVue.jsでの大規模開発に捧げるテスト駆動フロントエンド開発の...
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
Yuji Yamaguchi
July 25, 2019
Programming
6.6k
14
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
レガシーでウォーターフォールなVue.jsでの大規模開発に捧げるテスト駆動フロントエンド開発の話 / v-tokyo10
大規模ウォーターフォール開発の中で実施している、vue-testing-libraryを利用したテスト駆動開発の紹介です。
Yuji Yamaguchi
July 25, 2019
More Decks by Yuji Yamaguchi
See All by Yuji Yamaguchi
Oxlintはいいぞ(続)
yug1224
1
420
螺旋階段のように上がるEMの次のキャリア
yug1224
1
98
ルールを書いて終わらせないハーネスエンジニアリング
yug1224
5
1.9k
バラバラだった staleTime を、データの性質で4プリセットに集約する
yug1224
1
74
Oxcを導入して開発体験が向上した話
yug1224
5
470
EMからICへのキャリアチェンジの壁とその越え方
yug1224
5
350
Cursor Subagentsはいいぞ
yug1224
2
220
EMからICへ、二周目人材としてAI全振りのプロダクト開発で見つけた武器
yug1224
5
2.1k
Oxlintはいいぞ
yug1224
5
3.7k
Other Decks in Programming
See All in Programming
片田舎のおっさん、 Swift Buildのダイアモンド問題解決の不具合修正PRを出すが、解決方法がキャッシュをしないようにすることであり、ビルド時間が伸びると言われてマージされないので高速化もする/swiftbuild
yimajo
0
270
仕様駆動開発へのトライを機に チームに適合する手法を模索し続けている話
freee
PRO
0
600
Dockerfile CMD for Node.js
grazie1999
0
120
AIに既存システムを理解させる技術 ~レガシーを見捨てないハーネスエンジニアリング入門~
ochtum
0
140
Loosening the Reins: Go Generics Get More Flexible
kuro_kurorrr
0
300
進化を続けるGo toolsの現在地 / The Current State of Ever-Evolving Go Tools
hond0413
0
250
自動化したのに回らない テスト運用の壁―AI時代の品質責任と生産性
mfunaki
0
440
わからない話を追いかけたら、プログラミング言語を作る側にいた
ydah
3
540
S3 を使うアプリケーションをローカル完結で動かすことに全力を注いでみた / Running S3 Apps Offline
contour_gara
0
580
思考垂れ流し開発 ~音声入力 × AIエージェント × 開発ハーネスによる試行錯誤~
npostring
0
130
170k Jobs a Day on GKE: Scaling Mercari's CI Platform - and What's Next for AI-Native Development
junyaokabe
0
120
Webエンジニアなのにブラウザの仕組みがわからないので、Pythonで自作してみた
tatsuki12
4
1k
Featured
See All Featured
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
141
35k
Game over? The fight for quality and originality in the time of robots
wayneb77
1
250
エンジニアに許された特別な時間の終わり
watany
108
250k
AI Search: Implications for SEO and How to Move Forward - #ShenzhenSEOConference
aleyda
1
1.3k
AI in Enterprises - Java and Open Source to the Rescue
ivargrimstad
0
1.4k
Bridging the Design Gap: How Collaborative Modelling removes blockers to flow between stakeholders and teams @FastFlow conf
baasie
0
660
Exploring the relationship between traditional SERPs and Gen AI search
raygrieselhuber
PRO
2
4.2k
Accessibility Awareness
sabderemane
1
180
Primal Persuasion: How to Engage the Brain for Learning That Lasts
tmiket
0
430
Reflections from 52 weeks, 52 projects
jeffersonlam
356
21k
How to Think Like a Performance Engineer
csswizardry
28
2.7k
16th Malabo Montpellier Forum Presentation
akademiya2063
PRO
0
360
Transcript
レガシーでウォーターフォールな Vue.jsでの大規模開発 に捧げるテスト駆動フロン トエンド開発の話 2019/07/25 Vue.js v-tokyo Meetup #10 Yuji
Yamaguchi
自己紹介 2 ▸ 名前 ▸ ヤマグチ ユウジ ▸ 職種 ▸
フロントエンドエンジニア ▸ 経歴 ▸ 2011年04月 通信系企業 ▸ IoTやWebコンテンツサービスの開発運用 ▸ 2016年01月 ネット広告系企業 ▸ 広告配信管理システムの開発運用 ▸ 2016年10月 株式会社リクルートライフスタイル ▸ 飲食店向け予約台帳システムの開発
3 今日話すこと
飲食店向け予約台帳アプリ:レストランボード 4
None
None
元々は独自フレームワークだった ▸ jQuery製で、2014年末頃にfirst commit ▸ BabelifyでES2015にトランスパイル、 MorphDOMで差分レンダリングを実現 ▸ TemplateにModelを渡すとレンダリングし、
SelectorとFunctionを渡すとバインドするMVVMフレームワーク 7 Reactなどが話題になり始めた頃なので 実は少し影響を受けている
入力値を表示する場合 8
9 完成度は高いが 今後の継続性は
Vue.js導入はまずは足元を整えてから 10 2014/12 2016/10 2017/10 2018/10 2015/4 独自FW誕生 レストランボード 開発開始
脱Browserify 脱Grunt ESLint Jest Prettier Promise Vue.js async / await 案件開発をしながら、 二年かけて小さくリファクタリング
Vue.js導入時に心掛けたこと ▸ 小さく移行する ▸ Drasticに変えない ▸ 画面毎や部品毎、MoleculesやAtomsから導入 ▸ 案件で触る部分だけ、リファクタリングの粒度にとどめる ▸
レガシーコードのロジックは資産、できるだけそのまま使う 11 導入による大きなインシデントはなし!
現状の導入比率 12 45% 55% 62画面中34画面で導入済み
13 単体テストは完璧なのに 手戻りや結合バグが 多くなりがち
手戻りや結合バグを減らすには ▸ コンポーネント単位のテストだけでは、 実際のユースケースを確認できず不十分なことが多い ▸ バグの原因を辿ると要件定義漏れだったということも多く、 そもそもステークホルダーと要件を握りきれていなかったことも ▸ 最終成果物が不明瞭なので、 何を作ればいいのか何を作ってはいけないのかもわからない
14 これから作るものについての 合意形成がかなり重要
15 vue-testing- library
vue-testing-libraryとは ▸ dom-testing-libraryのVue用軽量アダプター ▸ Vueコンポーネントの実装に依存せず、 レンダリングされる実際のDOMノードを使ってテストを行う ▸ OSやブラウザ環境をブラックボックスにし、 実際のユーザー操作をシミュレートするテストを書くことができる 16
コンポーネント同士が結合された状態で より現実に近いテストを実施できる
カウンターアプリで考える 17
結合テストファースト 18 成果物イメージの合意形成のために テストケースの作成から始める
vue-testing-libraryの導入で良かったこと ▸ 要件を固めてから開発を進めるプロジェクトと相性が良かった ▸ これから作るものが明確になり、 開発工程でのQ&Aや手戻りを少なくすることができた ▸ 結合工程以降で検知されるバグ内容をOSやブラウザなどの 環境依存やデータパターンによるものに限定することができた 19
ToDoリストのようなテストケースがあることで 全体像の把握が容易になった
vue-testing-libraryの導入で難しかったこと ▸ テストケースの粒度の設定が難しい ▸ Mock/Stub/Spyを多用すると、テストコードの作成とメンテにコストがかか る上に、プロダクションコード実行時の状況とかけ離れてしまう場合がある ▸ テストコードを書く部分は自分たちが実装した部分だけ、 フレームワークやブラウザの処理までテストするテストコードは書かない 20
単体テストと結合テストの バランス調整が難しい
21 まとめ
まとめ 実コンポーネントに依存するテストは腐りやすい。 vue-testing-libraryを使うと、 コンポーネントが結合された実態に近い状態で 機能をテストすることができる。 単体テストでは拾えない結合バグや、 要件定義漏れによる手戻りの防止には、 製造する前のテストケース作成がオススメ。 22
23 EOF