コンポーネントのテストを書きました

最近書いたコンポーネントのテストで、よかったこと気づいたことをメモしておきます。主に react testing library を使っていて、それが前提になっています。

testing library 用の eslint rule が便利

• eslint-plugin-testing-library | Testing Library
  • 「ここではgetByXXXを使うな」とか、要素取得メソッドの矯正をしてくれる
  • screen.debug() もエラーにしてくれるので、消し忘れ防止になる
  • ただ targetElement.firstChild みたいに直接 DOM 取得すると怒られるのは少し不便（その行だけ無効にしてしまってる）

prop drilling したコールバックのテストがしんどい

• イベントを発火させて、コンポーネントに渡したコールバックが呼ばれていることを確認するテストを書きたい
  • イベントを発火するコンポーネントとテスト対象のコンポーネントが分かれているとき、さらにその二者が遠く離れているとき、イベント発火コンポーネントに至るまでの DOM 構造を知っていなければいけない問題がある
    • 直接の親子なら親は子に依存してるので、少しくらい知っていてもいいかと思うのだけど、孫やひ孫くらい離れていると知りすぎている感があってつらい
• コンポーネント毎にユニークなtest-idがあればいいのかもしれない
  • それでも DOM 上での登場順に気を配らなくてはいけないけども

SWR を使うときはキャッシュに気をつける

• どう考えてもテスト同士が干渉してる事象があった
  • テストAで削除のテストをやると、テストBでは削除されたあとの状態になっていた
• Cache – SWR
  • 回避策はここに書いてあった（読んでたはずだけど、テスト間でキャッシュするなんて思い至らなかった）

@mswjs/data が便利

• mswjs/data
  • mswjs/data で広がるテスト戦略 で知りました
• msw 単体で使うと取得系のテストは簡単に書けるようになるが、更新系のテストでは工夫が必要で悩んでいた
  • mswjs/data はその辺の面倒臭さをカバーしてくれるのでありがたい

React DnD テストしやすい

• React DnD にテストに関する章があるくらいドキュメントがきちんとしている
  • ただ test backend を使うのだと勘違いしていて、しばらくハマってしまった
    • testing-library は DOM を扱うので、通常使う HTML5 backend でよい
• userEventにdragイベントやdropイベントは実装されてないので、fireEventで扱うしかなかった
  • Simulate drag and drop · Issue #440 · testing-library/user-event
    • 実装する予定もなさそう

Intersection Observer は jsdom 環境でテストできない

• Support for Intersection Observer? · Issue #2032 · jsdom/jsdom
  • jsdom で Intersection Observer が実装されていなかった
  • ひとまず下記のようなコードで参照エラーになるのを回避して、実際にテストするのは e2e でやるしかないか？ と思ってます

const intersectionObserverMock = () => ({
  observe: () => null,
  disconnect: () => undefined,
});
window.IntersectionObserver = jest.fn().mockImplementation(intersectionObserverMock);

• issueを辿っていくとshopifyがmockを実装していた
  • quilt/intersection-observer.ts at main · Shopify/quilt

以上です