概要
小規模な案件で web application を作成する機会があり、単独で時間が限られていたため Next.js を利用することにした。私は FE に詳しくないため、0コンフィグとインターネット上の情報量の多さ、最悪社内の React ユーザーに泣きつくことを加味して Next.js を採用した。それでも、ユニットテストをパスさせるまでに労力が発生したので設定ファイルと、スグに試せるユニットテスト付きのテンプレートプロジェクトを用意した。↓
トラブルポイント
私の場合、トラブルポイントは2つ存在した。
node-mysql2
を導入すると jest でエラーが起きる
- こちらの記事と同じ問題
- jest.config.js と jest.setup.js に手を加える必要があった
モックを使おうとするとエラーが起きる
- 時刻の固定や外部サービスの連携部分をモックできないのが困る
- 結局、
jest.spyOn
を利用するのを諦めた- 余裕が無く、条件付きでモジュールをモックできたので妥協した
-
後日調査から Jest の Typescript Usage に従えば良いことがわかった
- https://jestjs.io/docs/mock-function-api#typescript-usage
- 当時このドキュメンテーションに気付けなかったのが辛い
時刻の mock
- 現在時刻の取得、時刻の操作には
moment
モジュールを利用している -
この部分 のように
describe
ブロックの外でmoment
モジュールをモックしてしまう- ブロック内に記述するとエラーになる
特定のモジュールの関数のモック
-
FE 側ではAPI を利用する部分を関数化 (
postHello
) して記述している -
この部分のように時刻の mock と同じように記述する
- 異常系をテストしたい場合が課題
- 数が少ない場合は引数の params に応じて返却値を決める
- 後日調査を行い、下記のドキュメント通りに記述するのが良いことが分かった
補足
とりわけ FE は詳しくないのでライブラリ選定に時間を取られた。社内の他案件を見る限りテスティングフレームワークは jest の採用が多いが、それら案件の package.json
はボリュームがあり、必要最低限のライブラリがどれか分からない。
特に testing-library
は下記の3つは始めから必要だと思うが、結局必要そうな場面で調査を行い、都度依存関係に加える対応となってしまった。
testing-library/react
testing-library/jest-dom
testing-library/user-event
一方、 API Route (BE) の方は next-test-api-route-handler
だけで良かったのでトラブルには見舞われなかった。
余談
- material ui の v5 は
@mui/material
,@mui/icons-material
- 始め v4 の
@material-ui
を依存関係に加えようとして間違えかけた