Nuxt.js And TestCode - Speaker Deck

Nuxt.js And TestCode

by keita-koga

Slide 1

Slide 1 text

Nuxt.jsとテストコード keitakn（古賀圭太）

Slide 2

Slide 2 text

自己紹介古賀圭太（keitakn）フリーランスエンジニア（主にWeb系） Twitter: https://twitter.com/keita_kn_web GitHub: https://github.com/keitakn Qiita: https://qiita.com/keitakn

Slide 3

Slide 3 text

今日お話すること ● Nuxt.js（Vue.js）のテストの種類について ● 実際にどんなテストコードを書くべきか？

Slide 4

Slide 4 text

テストコードを書く目的 ● 検証作業の工数を削減する為 ● バグを減らす為 ● リファクタリングを容易にする為

Slide 5

Slide 5 text

Nuxt.jsの主なテスト ● Componentのテスト ○ Snapshotテスト ○ Storybook（厳密にはテストではないが関連するのでここに書いてます） ● Vuexのテスト ○ getterのテスト ○ mutationのテスト ○ actionのテスト ● E2Eテスト

Slide 6

Slide 6 text

フロントエンドのテストは大変テストの種類が多く、全部書くと大変テストはメンテナンスが継続されないと意味がない効果が高い部分に絞って書くのが現実的

Slide 7

Slide 7 text

Component Componentの仕様 ● repeatNumberの数だけを表示

Slide 8

Slide 8 text

Componentのテスト JESTによるSnapshotテスト catTestDataの中身は↓

Slide 9

Slide 9 text

Snapshot こんな感じのSnapshotが出力される

Slide 10

Slide 10 text

Snapshotテストの概要 ● Snapshotファイルをバージョン管理に含めておく ● UIの変更があった場合テストは失敗する UIの変更が開発者の意図するものであった場合はSnapshotファイルを更新する JESTを実行する際に以下のオプションを付けるとSnapshotファイルが更新される（-u でも同じ） jest --updateSnapshot

Slide 11

Slide 11 text

Storybookと組み合わせるテストの時に利用したcatTestDataをStorybookでも利用する UIドキュメントとテストコードが連動するので分かりやすい

Slide 12

Slide 12 text

Storyファイルの中身

Slide 13

Slide 13 text

Storybookの見た目

Slide 14

Slide 14 text

Componentの設計・テストで意識すること ● コンポーネントの責務は小さく、ステートレスに設計する ● ロジックはできる限りVuex側に書く ● あくまでもユニットテストなので、単一Componentのテストを意識する ● 単純なComponentはテストを省いても良い最終的にはComponentが意図した表示が出来ている事を担保出来ればOK

Slide 15

Slide 15 text

Vuexのテスト結論を先に言うと最低限必要なのはactionのテスト actionが呼び出された結果、mutationがコミットされstateが変化する変化後のstateの値が意図した値かどうかを担保すれば良い

Slide 16

Slide 16 text

actionのテスト概要 QiitaのUserProfileを取得するaction 下記のようにテストの準備を行う ● createLocalVueを利用する ● テスト対象のstoreをimportする ● httpClientをimportする ○ APIの結果をMock化する為

Slide 17

Slide 17 text

actionのテスト（続き）

Slide 18

Slide 18 text

getterのテストテストを書く事は比較的簡単しかし複雑な計算を行っている等の事情がなければスキップしても良いと思う

Slide 19

Slide 19 text

mutationのテストこちらもテストを書く事は簡単しかし先程と紹介した要領でactionのテストを書いていれば、それで十分こちらもスキップしても大きな問題はないと思う

Slide 20

Slide 20 text

E2Eテスト利用するツール次第だが実装コストはそれほどでもない一方、外部要因によってテストが壊れる事が多い為、メンテナンスコストが高いしかしブラウザでの動作確認が担保されるのは大きい主要機能、操作が複雑なシナリオの正常系だけでもいいので実装する

Slide 21

Slide 21 text

E2Eテスト用ツール今までのテストはJEST + vue-test-utilsで行ってきた E2EテストではTestCafeを利用する https://devexpress.github.io/testcafe/

Slide 22

Slide 22 text

TestCafeの良いところ ● テストに利用するブラウザを実行時の引数で選択出来る ● 標準でTypeScriptをサポートしている ● WebDriverをインストールする必要がない下記の記事が詳しく解説していたので載せておきます。（参考）TestCafe超入門-マルチブラウザのE2Eをラクラク試す(WebDriver不要) https://qiita.com/naka_kyon/items/c3acbf3954d3db555476

Slide 23

Slide 23 text

E2Eテストの流れ 1. 対象のURLに移動する 2. ブラウザを操作し必要な操作を行う 3. セレクタでDOM構造を調べ意図した形になっているか確認する

Slide 24

Slide 24 text

E2Eテスト用のカスタムデータ属性こんな感じでdata属性を追加

Slide 25

Slide 25 text

カスタムデータ属性が必要な理由セレクタはidやclassでも可能ではあるしかしCSSのリファクタリング等の影響を受けテストが壊れる事を防ぐため、専用のデータ属性を持たせたほうが良い

Slide 26

Slide 26 text

E2Eテストのサンプルコード

Slide 27

Slide 27 text

サンプルコードの流れ 1. トップページからログインページに遷移する 2. Qiitaの認可サーバーにリダイレクト a. 未ログイン状態なので Qiita上のログインフォームにリダイレクトされる b. Qiitaのログインフォーム上でログイン IDとパスワードを入力 c. ログインボタンをサブミット 3. 認可サーバー上で「許可する」ボタンをサブミット 4. アプリケーションのMyページにリダイレクトされる 5. Myページ上のQiitaプロフィール画像が意図した物かどうかを確認

Slide 28

Slide 28 text

まとめ ● Componentのテスト ○ 最低限Snapshotテストを用意する ○ Storybookと連動させると効率が良い ○ コンポーネントの責務は小さく、ステートレスに設計する ○ ロジックをVuex側に寄せると楽 ○ 単一Componentのテストを意識する ○ 単純なComponentはテストを省いても良い ● Vuexのテスト ○ 重要なのはactionのテスト、それ以外は状況次第で省いても問題ない ● E2Eテスト ○ メンテコストが高いが効果も大きいので重要機能の正常系に絞って実装する

Slide 29

Slide 29 text

おわりテストコードは開発者を助ける各種類のテストをバランス良く追加するのがオススメテストコードのサンプルを書きました（TypeScriptです）テスト環境構築の参考になれば幸いです https://github.com/nekochans/nuxt-boilerplate