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
Yuji Yamaguchi
July 25, 2019
Programming
13
6.4k
レガシーでウォーターフォールなVue.jsでの大規模開発に捧げるテスト駆動フロントエンド開発の話 / v-tokyo10
大規模ウォーターフォール開発の中で実施している、vue-testing-libraryを利用したテスト駆動開発の紹介です。
Yuji Yamaguchi
July 25, 2019
Tweet
Share
More Decks by Yuji Yamaguchi
See All by Yuji Yamaguchi
メンバーの成長速度にバフをかける1on1ミーティング / 2024-12-06
yug1224
20
12k
強みを伸ばすキャリアデザイン
yug1224
3
480
インターンと盛り上げる全社員参加型Advent Calendarの作り方 / 2024-02-22-QiitaNight
yug1224
1
110
2022ランキング圏外から2023ランキング入りを実現したテックブログ運営について / 2023-07-28-QiitaEngineerFesta
yug1224
0
130
Qiitaいいね数をGASで計測している話 / 2023-07-24-HRBrainFlyHigh
yug1224
1
940
HRBrainの生態系を支えるフロントエンドチームの取り組み / 2023-06-22-AwEngineerMeetup
yug1224
0
89
明日使えるかもしれないGitテクニック / Gunma.web#47
yug1224
0
290
React+TypeScriptで拡張機能が開発できるRaycastのススメ / 20221027_Raycast
yug1224
1
910
DX向上委員会 / 20220922_dxhacklt
yug1224
1
210
Other Decks in Programming
See All in Programming
TypeScriptのmoduleオプションを改めて整理する
bicstone
4
400
AIコーディングの本質は“コード“ではなく“構造“だった / The essence of AI coding is not “code” but "structure
seike460
PRO
2
700
Building an Application with TDD, DDD and Hexagonal Architecture - Isn't it a bit too much?
mufrid
0
370
Interface vs Types ~型推論が過多推論~
hirokiomote
1
210
RubyKaigi Hack Space in Tokyo & 函館最速 "予習" 会 / RubyKaigi Hack Space in Tokyo & The Fastest Briefing of RubyKaigi 2026 in Hakodate
moznion
1
110
CQRS/ESのクラスとシステムフロー ~ RailsでフルスクラッチでCQRSESを組んで みたことから得た学び~
suzukimar
0
180
TypeScript Language Service Plugin で CSS Modules の開発体験を改善する
mizdra
PRO
3
2.1k
“技術カンファレンスで何か変わる?” ──RubyKaigi後の自分とチームを振り返る
ssagara00
0
200
【TSkaigi 2025】これは型破り?型安全? 真実はいつもひとつ!(じゃないかもしれない)TypeScript クイズ〜〜〜〜!!!!!
kimitashoichi
1
280
try-catchを使わないエラーハンドリング!? PHPでResult型の考え方を取り入れてみよう
kajitack
3
160
TypeScript エンジニアが Android 開発の世界に飛び込んだ話
yuisakamoto
6
840
ソフトウェア品質特性、意識してますか?AIの真の力を引き出す活用事例 / ai-and-software-quality
minodriven
19
6.4k
Featured
See All Featured
Facilitating Awesome Meetings
lara
54
6.4k
StorybookのUI Testing Handbookを読んだ
zakiyama
30
5.7k
The Language of Interfaces
destraynor
158
25k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
252
21k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.8k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
14
1.5k
BBQ
matthewcrist
88
9.6k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
31
1.2k
It's Worth the Effort
3n
184
28k
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
160
15k
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