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
210
Development of authorization system using Authlete and AWS
keitakn
0
1.4k
Other Decks in Technology
See All in Technology
プロジェクトマネジメント実践論|現役エンジニアが語る!~チームでモノづくりをする時のコツとは?~
mixi_engineers
PRO
3
140
TypeScript と歩む OpenAPI の discriminator / OpenAPI discriminator with TypeScript
kaminashi
1
120
Microsoft Season of Agent AI エージェントの使用開始
takas0522
0
120
他チームへ越境したら、生データ提供ソリューションのクエリ費用95%削減へ繋がった話 / Cross-Team Impact: 95% Off Raw Data Query Costs
yamamotoyuta
0
170
君だけのオリジナル async / await を作ろう / TSKaigi 2025
susisu
17
13k
Eight Engineering Unit 紹介資料
sansan33
PRO
0
3.1k
AIオンボーディングとAIプロセスマイニング
nrryuya
5
1.2k
GitHub Coding Agent 概要
kkamegawa
1
1.1k
Rebase エンジニアリング組織の現状とこれから
rebase_engineering
0
130
型がない世界に生まれ落ちて 〜TypeScript運用進化の歴史〜
narihara
1
200
テストを実施する前に考えるべきテストの話 / Thinking About Testing Before You Test
nihonbuson
PRO
12
1.9k
OSMnx Galleryの紹介
mopinfish
0
140
Featured
See All Featured
Code Reviewing Like a Champion
maltzj
523
40k
Art, The Web, and Tiny UX
lynnandtonic
298
21k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
830
Building Adaptive Systems
keathley
41
2.6k
Building Better People: How to give real-time feedback that sticks.
wjessup
368
19k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
45
9.6k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
Practical Orchestrator
shlominoach
187
11k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
30
2.1k
How STYLIGHT went responsive
nonsquared
100
5.6k
The Power of CSS Pseudo Elements
geoffreycrofte
76
5.8k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
15
880
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