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
Nuxt.js And TestCode
Search
keita-koga
August 26, 2019
Technology
2
4.7k
Nuxt.js And TestCode
NuxtMeetUp#9 オールスターズ 登壇資料
「Nuxt.jsとテストコード」
https://nuxt-meetup.connpass.com/event/135514/
keita-koga
August 26, 2019
Tweet
Share
More Decks by keita-koga
See All by keita-koga
AWSFargateHandsOnStartingWithTerraform
keitakn
0
220
Development of authorization system using Authlete and AWS
keitakn
0
1.4k
Other Decks in Technology
See All in Technology
ゼロコード計装導入後のカスタム計装でさらに可観測性を高めよう
sansantech
PRO
1
440
組織全員で向き合うAI Readyなデータ利活用
gappy50
1
420
Implementing and Evaluating a High-Level Language with WasmGC and the Wasm Component Model: Scala’s Case
tanishiking
0
180
AI駆動で進める依存ライブラリ更新 ─ Vue プロジェクトの品質向上と開発スピード改善の実践録
sayn0
1
320
マルチエージェントのチームビルディング_2025-10-25
shinoyamada
0
180
OCIjp_Oracle AI World_Recap
shinpy
1
180
AIでデータ活用を加速させる取り組み / Leveraging AI to accelerate data utilization
okiyuki99
0
200
プレイドのユニークな技術とインターンのリアル
plaidtech
PRO
1
360
OpenTelemetry が拡げる Gemini CLI の可観測性
phaya72
2
2.3k
Biz職でもDifyでできる! 「触らないAIワークフロー」を実現する方法
igarashikana
7
3.4k
様々なファイルシステム
sat
PRO
0
240
QA業務を変える(!?)AIを併用した不具合分析の実践
ma2ri
0
150
Featured
See All Featured
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.6k
Principles of Awesome APIs and How to Build Them.
keavy
127
17k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
127
54k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
15k
Code Review Best Practice
trishagee
72
19k
Building Applications with DynamoDB
mza
96
6.7k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
3.1k
Build your cross-platform service in a week with App Engine
jlugia
233
18k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
Automating Front-end Workflow
addyosmani
1371
200k
Raft: Consensus for Rubyists
vanstee
140
7.2k
What's in a price? How to price your products and services
michaelherold
246
12k
Transcript
Nuxt.jsとテストコード keitakn(古賀圭太)
自己紹介 古賀圭太(keitakn) フリーランスエンジニア(主にWeb系) Twitter: https://twitter.com/keita_kn_web GitHub: https://github.com/keitakn Qiita: https://qiita.com/keitakn
今日お話すること • Nuxt.js(Vue.js)のテストの種類について • 実際にどんなテストコードを書くべきか?
テストコードを書く目的 • 検証作業の工数を削減する為 • バグを減らす為 • リファクタリングを容易にする為
Nuxt.jsの主なテスト • Componentのテスト ◦ Snapshotテスト ◦ Storybook(厳密にはテストではないが関連するのでここに書いてます) • Vuexのテスト ◦
getterのテスト ◦ mutationのテスト ◦ actionのテスト • E2Eテスト
フロントエンドのテストは大変 テストの種類が多く、全部書くと大変 テストはメンテナンスが継続されないと意味がない 効果が高い部分に絞って書くのが現実的
Component Componentの仕様 • repeatNumberの数だけ を表示
Componentのテスト JESTによるSnapshotテスト catTestDataの中身は↓
Snapshot こんな感じのSnapshotが出力される
Snapshotテストの概要 • Snapshotファイルをバージョン管理に含めておく • UIの変更があった場合テストは失敗する UIの変更が開発者の意図するものであった場合はSnapshotファイルを更新する JESTを実行する際に以下のオプションを付けるとSnapshotファイルが更新される(-u で も同じ) jest
--updateSnapshot
Storybookと組み合わせる テストの時に利用したcatTestDataをStorybookでも利用する UIドキュメントとテストコードが連動するので分かりやすい
Storyファイルの中身
Storybookの見た目
Componentの設計・テストで意識すること • コンポーネントの責務は小さく、ステートレスに設計する • ロジックはできる限りVuex側に書く • あくまでもユニットテストなので、単一Componentのテストを意識する • 単純なComponentはテストを省いても良い 最終的にはComponentが意図した表示が出来ている事を担保出来ればOK
Vuexのテスト 結論を先に言うと最低限必要なのはactionのテスト actionが呼び出された結果、mutationがコミットされstateが変化する 変化後のstateの値が意図した値かどうかを担保すれば良い
actionのテスト 概要 QiitaのUserProfileを取得するaction 下記のようにテストの準備を行う • createLocalVueを利用する • テスト対象のstoreをimportする • httpClientをimportする
◦ APIの結果をMock化する為
actionのテスト(続き)
getterのテスト テストを書く事は比較的簡単 しかし複雑な計算を行っている等の事情がなければスキップしても良いと思う
mutationのテスト こちらもテストを書く事は簡単 しかし先程と紹介した要領でactionのテストを書いていれば、それで十分 こちらもスキップしても大きな問題はないと思う
E2Eテスト 利用するツール次第だが実装コストはそれほどでもない 一方、外部要因によってテストが壊れる事が多い為、メンテナンスコストが高い しかしブラウザでの動作確認が担保されるのは大きい 主要機能、操作が複雑なシナリオの正常系だけでもいいので実装する
E2Eテスト用ツール 今までのテストはJEST + vue-test-utilsで行ってきた E2EテストではTestCafeを利用する https://devexpress.github.io/testcafe/
TestCafeの良いところ • テストに利用するブラウザを実行時の引数で選択出来る • 標準でTypeScriptをサポートしている • WebDriverをインストールする必要がない 下記の記事が詳しく解説していたので載せておきます。 (参考)TestCafe超入門-マルチブラウザのE2Eをラクラク試す(WebDriver不要) https://qiita.com/naka_kyon/items/c3acbf3954d3db555476
E2Eテストの流れ 1. 対象のURLに移動する 2. ブラウザを操作し必要な操作を行う 3. セレクタでDOM構造を調べ意図した形になっているか確認する
E2Eテスト用のカスタムデータ属性 こんな感じでdata属性を追加
カスタムデータ属性が必要な理由 セレクタはidやclassでも可能ではある しかしCSSのリファクタリング等の影響を受けテストが壊れる事を防ぐため、 専用のデータ属性を持たせたほうが良い
E2Eテストのサンプルコード
サンプルコードの流れ 1. トップページからログインページに遷移する 2. Qiitaの認可サーバーにリダイレクト a. 未ログイン状態なので Qiita上のログインフォームにリダイレクトされる b. Qiitaのログインフォーム上でログイン
IDとパスワードを入力 c. ログインボタンをサブミット 3. 認可サーバー上で「許可する」ボタンをサブミット 4. アプリケーションのMyページにリダイレクトされる 5. Myページ上のQiitaプロフィール画像が意図した物かどうかを確認
まとめ • Componentのテスト ◦ 最低限Snapshotテストを用意する ◦ Storybookと連動させると効率が良い ◦ コンポーネントの責務は小さく、ステートレスに設計する ◦
ロジックをVuex側に寄せると楽 ◦ 単一Componentのテストを意識する ◦ 単純なComponentはテストを省いても良い • Vuexのテスト ◦ 重要なのはactionのテスト、それ以外は状況次第で省いても問題ない • E2Eテスト ◦ メンテコストが高いが効果も大きいので重要機能の正常系に絞って実装する
おわり テストコードは開発者を助ける 各種類のテストをバランス良く追加するのがオススメ テストコードのサンプルを書きました(TypeScriptです) テスト環境構築の参考になれば幸いです https://github.com/nekochans/nuxt-boilerplate