UIコンポーネントテストをいきなり書くのは難しい。最初にテストを書く流れを抑えたあと書き始めると良い。
- テスト用ライブラリの思想を理解する（最初の1回のみ）
- UIコンポーネントの仕様を言語化する
- 言語化したものを元にTODOリストを作る
- TODOリストを元にテストケースを1つ書き、失敗させる
- テストを通す
- 以降は4と5を繰り返す
テスト用ライブラリの思想を理解する（最初の1回のみ）
テストに使うライブラリの思想を理解すると、効率的に要素のクエリを組み立てることができる。
例えばTesting LibraryはDOMのレンダリング結果、つまりユーザーが画面を利用する状況を作り出してテストすることを推奨している。1この思想を反映するような形でクエリが設定されているため、UIコンポーネント内でどのように状態が管理されているか、propsのやり取り結果は探索できない。もちろんコンポーネントそのものがレンダリングされているか、も探索できない。UIコンポーネントの有無をテストしたい場合、「コンポーネントの中にテキストが含まれていれば指定のテキストがレンダリングされている = コンポーネントが表示されている」ように捉え直してテストする必要がある。
一方、Vue Test UtilsではVue.jsで書かれたUIコンポーネントのテストに特化している。よって、Vue.jsの内部実装に深く入り込んだ形でテストケースを記載できる。例えばその代わり、findComponent()2というAPIを使うとUIコンポーネントを探し出すことができる。Testing Libraryでは難しかった「特定のUIコンポーネントの有無をテストする」ことができる。propsや内部の状態も操作できる3。代わりにユーザー操作視点でのテストは苦手である。
このように、テストライブラリごとに得意・不得意が分かれている。テストケースを考える際、可能な限りテストライブラリが苦手とすることを避けると良い。散々テストケースを考えた挙句、不得意な分野だったので代わりの手段を考え直す手間を省くためである。
仕様の言語化とTODO化
UIコンポーネントの記載や編集を始める前に、仕様を言語化しておく。UIコンポーネントを書くとき、見た目・イベントに応じた処理の発火・状態管理など様々なことを考慮しなければならない。仕様を整理せずに書き始めてしまうと、うまくいかないときに焦ってしまい完成から遠ざかってしまう。
また、仕様の整理を行わずにUIコンポーネントテストを後から追記すると「実は仕様を表現できていないがテストが通ってしまうため間違いに気づかなかった」ことによる不具合を作り込んでしまう。よって、先に仕様を整理し、それをTODOリストに起こしておく。こうすることで見落としや考慮漏れを防げる。
先にテストを書いて失敗させる
UIコンポーネントテストの難しさの要因に「セットアップが難しい」ことがあった。この難しさを取り除くため、テストケースを作り込む前に必ずテスト実行ができる状態にしておく。先に作り込んでしまうとテストが動作しない場合、何が悪いのか切り分けられなくなってしまう。
「テキストが取得できる」レベルで良いのでテストを書き、失敗することを確認してからUIコンポーネントを書き始める。先に成功させようとすると、「実は仕様を表現できていないがテストが通ってしまうため間違いに気づかなかった」状態になりやすい。テスト駆動開発4のように、先にTODOリストを作りテストを失敗させてからコードを書き始める方が早く確実に終わる。
