
これは、[Kent C. Dodds 氏](https://kentcdodds.com/)のブログ記事である[Write tests. Not too many. Mostly integration.](https://kentcdodds.com/blog/write-tests)を日本語訳してみたものです。

誤訳などあれば[Issue](https://github.com/makotot/makotot.dev/issues/new)や PR を頂けると幸いです。

---

このブログ記事は、こちらでご覧いただける講演を記事にしたものです:

<div className="content-center">
  <iframe src="https://www.youtube.com/embed/Fha2bVoC8SE?list=PLV5CVI1eNcJgNqzNwcs4UKrlJdhfDjshf" title="Kent C. Dodds – Write tests. Not too many. Mostly integration." frameBorder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowFullScreen></iframe>
</div>

少し前に、[Socket.io](https://socket.io)の作者であり[Zeit.co](https://zeit.co)（最近発表された多くの素晴らしいものを生み出している会社）のファウンダーでもある[Guillermo Rauch氏](https://twitter.com/rauchg)が[深いことをツイートしました](<(https://twitter.com/rauchg/status/807626710350839808)>)。

<div className="content-center">
  <blockquote className="twitter-tweet"><p lang="en" dir="ltr">Write tests. Not too many. Mostly integration.</p>&mdash; Guillermo Rauch (@rauchg) <a href="https://twitter.com/rauchg/status/807626710350839808?ref_src=twsrc%5Etfw">December 10, 2016</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charSet="utf-8"></script>
</div>

> **_テストを書きましょう。あまり多くなりすぎないように。主に結合テストで。_**

これは短いにも関わらず深いことなので、掘り下げてみましょう。

## テストを書きましょう。

そうです、ほとんどのプロジェクトでは自動化されたテストを書くべきです。時間に価値があるのならとにかくそうするべきです。
午前2時に電話をもらってバグを修正するよりも、テストによってローカルでバグを発見する方がはるかに良いです。
**テストを書くことに時間を費やすと時間の節約になっていることに気づくことがよくあります。**
作るものにかかる実装の時間は長くなるかもしれないし、そうじゃないかもしれないけど、私（や他の人）がそれを維持することに費やす時間はほぼ間違いなく節約できます。

テストを書くときに考えるべきことは、プロジェクトにバグがないか確信を持つことがどれだけできるかどうか、です。
[TypeScript](https://www.typescriptlang.org)や[ESLint](https://eslint.org)のような静的型付けツールやリントツールは驚くほどの信頼性をもたらすので、
もしこれらのツールを利用していないのであれば使ってみることを強くお勧めします。
とはいえ、**強く型付けされた言語であってもテストがあるべきです**。型付けやリントは、ビジネスロジックにバグがないことを保証できません。
そのため、良いテストスイートによって信頼性を高めることが出来ます。

## あまり多くなりすぎないように。

私は、マネージャーやチームがアプリケーションに対する100%のコードカバレッジを義務としているのを耳にしたことがあります。
それは本当に良くない考えです。問題は、**カバレッジが70%を優に超える状態になると、テストから得られるものが少なくなる**（数字は私が科学的根拠なく出したものです。。）ことにあります。
なぜでしょうか？それは、常に100%を目指しているとテストする必要のないものまでテストすることに時間を費やすようになるのです。
それらは本当にロジックを全く持たないものです（バグがあればESLintやFlowで発見できます）。
_このようなテストの維持は本当にあなたやあなたのチームの速度を低下させます。_

また、テスト環境で再現困難な1行のコードの確認をするためだけに実装詳細をテストしていることに気づくこともあるでしょう。
アプリケーションが動いていることに十分な信頼性を得られず、リファクタリング時に速度低下を招くので、実装詳細をテストすることは _本当に_ 避けたいものです。
**リファクタリング時にテストを修正することは、滅多にするべきではありません。**

私のほとんど全てのオープンソースプロジェクトが100%のコードカバレッジであることに触れておくべきでしょう。私のオープンソースプロジェクトはさまざまな状況で再利用できる小さなライブラリーやツールばかり
（壊れると利用している多くのプロジェクトで重大な問題を招きます）で、とにかく相対的に100%のコードカバレッジを得やすいものです。

## 主に結合テストで。

テストにはさまざまな種類があります（これについてはFluent Confにおける私の5分の講演をご覧ください：["What we can learn about testing from the wheel"](https://youtu.be/Da9wfQ0frGA?list=PLV5CVI1eNcJgNqzNwcs4UKrlJdhfDjshf)）
それぞれにトレードオフがあります。自動テストについて話題にするとき最も一般的な3つのテストの形態は、単体、結合、そしてE2Eです。

こちらは、私のフロントエンドマスターズワークショップ["Testing JavaScript Applications"](https://frontendmasters.com/courses/testing-javascript)での[スライド](http://slides.com/kentcdodds/testing-workshop#/4/8)です。

![テストピラミッド](/images/content/write-tests-translation-ja/test-pyramid.png)

このテストピラミッドは、[マーティン・ファウラー氏のブログ](https://martinfowler.com/bliki/TestPyramid.html)と[Googleのテストのブログ](https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html)から組み合わせたものです。

ここで示しているように、ピラミッドは下から上へ、単体、結合、E2Eの順になっています。
ピラミッドの上へ向かうほどテストの記述/実行に時間がかかり、実行/維持に（時間とリソースの面で）より高いコストがかかります。
これによって、単体テストへより多くの時間を割くべきということを示すものです。

ここで示されていないことは、**ピラミッドの上へ向かうほど各テスト形態の信頼指数が高まる**ということです。より多くの利益を得られるのです。
つまり、E2Eテストは単体テストよりも遅くコストが高いものですが、アプリケーションが意図通りに動作していることに対してより大きな信頼をもたらします。

<div className="content-center">
  <blockquote className="twitter-tweet"><p lang="en" dir="ltr">The TestPyramid blog post by <a href="https://twitter.com/martinfowler?ref_src=twsrc%5Etfw">@martinfowler</a> (<a href="https://t.co/RCv8abFm37">https://t.co/RCv8abFm37</a>) finishes with this note.<br /><br />Our tools are awesome now and this assumption is less true. This is why I say goodby to the pyramid 🔼 and hello to the trophy 🏆 <a href="https://t.co/EKTK4vqj6n">https://t.co/EKTK4vqj6n</a> <a href="https://t.co/Wa8brUiWfy">pic.twitter.com/Wa8brUiWfy</a></p>&mdash; Kent C. Dodds 🌌 (@kentcdodds) <a href="https://twitter.com/kentcdodds/status/1141365123296051201?ref_src=twsrc%5Etfw">June 19, 2019</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charSet="utf-8"></script>
</div>

上記の通り、我々のツールはマーティン・ファウラー氏によるテストピラミッドのコンセプトの想定を超えたものになっています。”テストトロフィー”を作った理由がここにあります 🏆。

<div className="content-center">
  <blockquote className="twitter-tweet"><p lang="en" dir="ltr">&quot;The Testing Trophy&quot; 🏆<br /><br />A general guide for the **return on investment** 🤑 of the different forms of testing with regards to testing JavaScript applications.<br /><br />- End to end w/ <a href="https://twitter.com/Cypress_io?ref_src=twsrc%5Etfw">@Cypress_io</a> ⚫️<br />- Integration &amp; Unit w/ @fbjest 🃏<br />- Static w/ <a href="https://twitter.com/flowtype?ref_src=twsrc%5Etfw">@flowtype</a> 𝙁 and <a href="https://twitter.com/geteslint?ref_src=twsrc%5Etfw">@geteslint</a> ⬣ <a href="https://t.co/kPBC6yVxSA">pic.twitter.com/kPBC6yVxSA</a></p>&mdash; Kent C. Dodds 🌌 (@kentcdodds) <a href="https://twitter.com/kentcdodds/status/960723172591992832?ref_src=twsrc%5Etfw">February 6, 2018</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charSet="utf-8"></script>
</div>

こちらは、結合テストの重要性をユーモラスに説明したものです。

<div className="content-center">
  <blockquote className="twitter-tweet"><p lang="en" dir="ltr">expect(umbrellaOpens).toBe(true)<br /><br />tests: 1 passed, 1 total<br /><br />**all tests passed** <a href="https://t.co/p6IKO7KDuy">pic.twitter.com/p6IKO7KDuy</a></p>&mdash; Erin 🐠 (@erinfranmc) <a href="https://twitter.com/erinfranmc/status/1148986961207730176?ref_src=twsrc%5Etfw">July 10, 2019</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charSet="utf-8"></script>
</div>

コンポーネント`<B />`にprop`e`が渡らずに壊れる場合には、コンポーネント`<A />`が`c`と`d`のpropsを受け取るコンポーネント`<B />`をレンダリングするかどうかは問題ではありません。
そのため、これらの部品が独立して機能することを検証する単体テストを幾らか持つことは悪いことではないですが、_それらが適切に連携して機能すること**も**検証しないとあまり意味がありません_。
そして、適切に連携して機能することをテストすることで、わざわざ独立して個別にテストする必要がないと気づくことが多々あるでしょう。

**結合テストは、信頼性とスピード/費用とのトレードオフの間で素晴らしいバランスが保たれます。**
そのため、_ほとんど_（全てではないけども）の労力をここに費やすことをお勧めします。

<div style={{
  padding: "0.5rem",
  border: "1px solid hsl(var(--p)",
}}>
これに関して詳しくは[Testing Implementation Details](https://kentcdodds.com/blog/testing-implementation-details)を読んでください。
テストの形態について詳しくは、[Static vs Unit vs Integration vs E2E Testing for Frontend Apps](https://kentcdodds.com/blog/static-vs-unit-vs-integration-vs-e2e-tests)を読んでください。
</div>

## より多くの結合テストを書く方法

結合テストと単体テストとの境界線はやや曖昧です。とにかく、より多くの結合テストを書くのにできる最も大きなことは**あまり多くのことをモックするのをやめる**ことだと思います。
_何かをモックすると、テストしているものとモックされているものの間の結合における全ての信頼を除去していることになります。_
私は、モックが（[異論もあると思いますが](https://youtu.be/EaxDl5NPuCA)）[時に避けられないもの](https://kentcdodds.com/blog/the-merits-of-mocking)だとも理解しています。
毎回テストで _実際に_ メールを送信したりクレジットカードで支払ったりはしたくないと思いますが、大抵の場合においてモックを避けることは可能あり、そうすることでより良くなるでしょう。

**Reactを利用しているのであれば、シャローレンダリングもモックに含まれます。** より詳しくは[Why I Never Use Shallow Rendering](https://kentcdodds.com/blog/why-i-never-use-shallow-rendering)を読んでください。

## 結論

ソフトウェアのテストが時間の無駄だと異論を唱える人はいないと思います。
最大の課題は、[実装詳細をテスト](https://kentcdodds.com/blog/testing-implementation-details)することによる誤った信頼ではなく、
[何をテストするべきか知り](https://kentcdodds.com/blog/how-to-know-what-to-test)、それをどのようにして[本当の信頼](https://kentcdodds.com/blog/confidently-shipping-code)を得るテストとするかです。

この記事がお役に立てば幸いです。また自信を持ってアプリケーショを届ける目標が達成されることを祈っています！


テストを書きましょう。あまり多くなりすぎないように。主に結合テストで。


これは、[Dominik Dorfmeister 氏](https://tkdodo.eu/)のブログ記事である[Status Checks in React Query](https://tkdodo.eu/blog/status-checks-in-react-query)を日本語訳してみたものです。

誤訳などあれば[Issue](https://github.com/makotot/makotot.dev/issues/new)や PR を頂けると幸いです。

---

React Query の利点の 1 つはクエリのステータスへのアクセスが容易であることです。クエリーが読み込み中であるのか、エラーが起きているのか、すぐにわかります。
このために、このライブラリーは内部のステートマシーンに由来する多くの真偽値を公開しています。[型定義](https://github.com/tannerlinsley/react-query/blob/f2137dc4e4553256c4ebc1891b548fe35efe9231/src/core/types.ts#L250)を見てみると、クエリーは以下のいずれかの状態になります。

- `success`: クエリーは成功して`data`がある
- `error`: クエリーは機能せず、`error`がセットされる
- `loading`: クエリーはデータを持たず、現在初回の`loading`中である
- `idle`: `enabled`ではないのでクエリーが 1 度も実行されていない

**更新**: React Query の v4 において、idle 状態は削除されました。`loading`の状態は、ただ”データがまだない”ことを示します。

`isFetching`フラグが内部のステートマシーンの 1 部**_ではない_**ことに留意してください。これはリクエスト中であれば常に真となる付加的なフラグです。フェッチ中かつ成功、フェッチ中かつエラーにはなり得ますが、同時に読み込み中かつ成功とはなり得ません。ステートマシーンがこれを保証します。

**更新**: v4 において、`isFetching`フラグは補助的な`fetchStatus`から導き出されます。新しいフラグの`isPaused`と同じように。より詳しくは[#13: Offline React Query](https://tkdodo.eu/blog/offline-react-query)をご覧ください。

## 標準的な例

無効なクエリーのためのエッジケースなので`idle`状態は大抵省かれます。そのためほとんどの例はこのようになります。

```jsx standard-example
const todos = useTodos()

if (todos.isLoading) {
  return 'Loading...'
}
if (todos.error) {
  return 'An error has occurred: ' + todos.error.message
}

return <div>{todos.data.map(renderTodo)}</div>
```

ここでは、まず最初にエラーと読み込み中のチェックを行います。これはおそらく、適切なユースケースと不適切なユースケースがそれぞれあります、。データ取得の解決策の多く、特に手製のものは、再取得のメカニズムを持たないか、明示的なユーザ操作に限っての再取得になります。

でも、React Query は違います。

デフォルトで非常に積極的に再取得し、ユーザーが能動的に再取得をリクエストしなくてもそうします。
`refetchOnMount`、`refetchOnWindowFocus`、`refetchOnReconnect`などはデータの正確さを保つのに素晴らしいものですが、自動的なバックグラウンド処理が失敗した時、分かりにくい UX になるかもしれません。

## バックグラウンドのエラー

多くの場面で、バックグラウンドでの再取得が失敗したら、ひっそりと無視されるかもしれません。しかし、上述のコードではそうなりません。ここで 2 つの例を見てみましょう。

- ユーザーがページを開いて、初回のクエリーがうまく読み込まれます。しばらくの間その画面で操作を行い、メールをチェックするのにブラウザーのタブを切り替えます。数分後に戻ってきた時、React Query はバックグラウンドで再取得を行います。今回、再取得は失敗します。
- ユーザーがリストビューの画面にいて、任意のアイテムをクリックして詳細なビューへ掘り下げます。これはうまくいったので、リストビューへと戻ります。再び詳細なビューへ行くとキャッシュのデータを目にすることになります。これは素晴らしいですね、バックグラウンドでの再取得が失敗する場合を除いては。

どちらの場合でも、クエリーの状態はこのようになります。

```json
{
  "status": "error",
  "error": { "message": "Something went wrong" },
  "data": [{ ... }]
}
```

ご覧の通り、エラーと古いデータと**_両方が_**存在します。これが React Query の素晴らしいところです。stale-while-revalidate のキャッシュのメカニズムを採用していて、たとえデータが古くなっていてもデータが存在すれば常に提供することができます。

何を表示するかは私たち次第です。エラーを表示することが重要ですか？古いデータがある場合、それだけ表示すれば十分ですか？少し**_バックグラウンドのエラー_**を表示しつつ両方表示するべきですか？

この問いに明確な答えはありません。ユースケースに依存します。しかしながら上述の 2 つの例に関していえば、データがエラー画面に置き換えられてしまうのは幾分紛らわしい UX のように思えます。

これは React Query が失敗したクエリーをエクスポネンシャルバックオフによるデフォルトで 3 度リトライすることを考慮するとより関連性が高く、古いデータがエラー画面に置き換わるのに数秒かかるかもしれません。
バックグラウンドでの再取得を示すインジケーターがなければ、本当に理解しにくいものになるでしょう。

私が大抵データの存在を最初にチェックするのはこのためです。

```jsx data-first
const todos = useTodos()

if (todos.data) {
  return <div>{todos.data.map(renderTodo)}</div>
}
if (todos.error) {
  return 'An error has occurred: ' + todos.error.message
}

return 'Loading...'
```

もう 1 度言いますが、何が正しいかという明確な原則はなく、ユースケースに強く依存します。積極的な再取得がもたらす結果を誰もが把握するべきで、単純な todo の例に従うよりも適宜コードを構成する必要があります。

なぜこのようなステータスチェックのパターンがある状況下で有害となり得るのかを最初に強調してくれた[Niek Bosch 氏](https://github.com/boschni)に特別な感謝を送ります。


React Queryにおけるステータスチェック


これは、[Dominik Dorfmeister 氏](https://tkdodo.eu/)のブログ記事である[Testing React Query](https://tkdodo.eu/blog/testing-react-query)を日本語訳してみたものです。

誤訳などあれば[Issue](https://github.com/makotot/makotot.dev/issues/new)や PR を頂けると幸いです。

---

テストのトピックに関する質問をよく React Query と合わせてもらうので、ここでその中のいくつかに答えましょう。
私はその理由の 1 つを、”スマート”なコンポーネント（[コンテナーコンポーネント](https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0)とも呼ばれます）のテストが簡単ではないからだと考えます。フックの登場により、この分割手法は概ねほぼ非推奨となりました。今では、ほぼ恣意的な分割とプロップドリルよりも、必要な場所で直接フックを使用することが推奨されるようになっています。

私は、これが全体的にコロケーションやコードの可読性に対するとても良い改善だと考えますが、”ただの props”以外の依存関係を用いるコンポーネントが増えることにもなります。

それは`useContext`かもしれません。`useSelector`かもしれません。はたまた`useQuery`かもしれません。

このようなコンポーネントは、異なる状況で呼ばれると異なる結果が返されるので、技術的にはもはやピュアなものではありません。テストする際、適切に動作するよう注意深く周辺環境を設定しておく必要があります。

## ネットワークリクエストのモック

React Query が非同期のサーバーステート管理ライブラリなので、コンポーネントはバックエンドへリクエストをするかもしれません。テストする際に、このバックエンドから実際にデータを提供できないし、例えできたとしても、それに依存したテストにしたくはないでしょう。

jest でデータをモックする方法についての記事は大量にあります。API クライアントがあればそれをモックできます。fetch や axios を直接モックもできます。私はただ Kent C. Dodds 氏による記事の[Stop mocking fetch](https://kentcdodds.com/blog/stop-mocking-fetch)に賛同をするだけです。

[@ApiMocking](https://twitter.com/ApiMocking)による[mock service worker](https://mswjs.io/)を利用しましょう。

API をモックすることで信頼できる唯一の情報源とすることができます。

- テストにおいて Node.js で動作します
- REST も GraphQL もサポートしています
- [Storybook のアドオン](https://storybook.js.org/addons/msw-storybook-addon)があるので、`useQuery`を使っているコンポーネントをストーリーを書くことができます
- 開発用にブラウザで動作し、ブラウザの開発者ツールでリクエストを確認できます
- フィクスチャー同様に Cypress で動作します

---

ネットワークレイヤーのケアが済んだので、React Query 特有のことに目を向けていきましょう。

## QueryClientProvider

React Query を使用するときは常に QueryClientProvider とそれに渡す queryClient - `QueryCache`を保持する容器 - が必要です。キャッシュはクエリーのデータを順番に保持します。

私はテスト毎に固有の QueryClientProvider を持たせることとテスト毎に`new QueryClient`を生成することを好みます。こうすることでテストはお互い完全に隔離されます。テスト毎にキャッシュをクリアする方法もあるかもしれませんが、私はテスト間で共有する状態を可能な限り小さくしたいと思っています。そうしなければ、並行してテストを実行したら予期しきれないフレーキーな結果が返されるかもしれません。

### カスタムフックの場合

カスタムフックをテストする場合、[react-hooks-testing-library](https://react-hooks-testing-library.com/)を間違いなく利用するでしょう。これはフックをテストするための最も簡単なものです。このライブラリによって、レンダリング時にテストするコンポーネントを包み込む React コンポーネントである[ラッパー](https://react-hooks-testing-library.com/reference/api#wrapper)にフックを包むことができます。私は、これがテスト毎に 1 度実行されるものであるため、QueryClient を生成するのに完璧な場所だと思います。

```tsx wrapper
const createWrapper = () => {
  // ✅ テスト毎に新しいQueryClientを生成する
  const queryClient = new QueryClient()
  return ({ children }) => (
    <QueryClientProvider client={queryClient}>{children}</QueryClientProvider>
  )
}

test("my first test", async () => {
  const { result } = renderHook(() => useCustomHook(), {
    wrapper: createWrapper()
  })
})
```

### コンポーネントの場合

`useQuery`フックを使うコンポーネントをテストしたい場合においても、そのコンポーネントを QueryClientProvider でラップする必要があります。[react-testing-library](https://testing-library.com/docs/react-testing-library/intro/)の`render`を包む小さなラッパーは良い選択に思えます。React Query が[自身の内部のテスト](https://github.com/tannerlinsley/react-query/blob/ead2e5dd5237f3d004b66316b5f36af718286d2d/src/react/tests/utils.tsx#L6-L17)をどのように行なっているか見ておきましょう。

## リトライの無効化

これは、React Query とテストでのよくある”潜在的問題”の 1 つです。ライブラリの初期値は指数関数的なバックオフで 3 回リトライし、即ち、誤ったクエリーをテストしたい時にタイムアウトする可能性があることを意味します。リトライを無効化する最も簡単な方法もまた`QueryClientProvider`を通して行います。上述の例を拡張しましょう。

```tsx no-retries
const createWrapper = () => {
  const queryClient = new QueryClient({
    defaultOptions: {
      queries: {
        // ✅ リトライを無効化する
        retry: false,
      },
    },
  })

  return ({ children }) => (
    <QueryClientProvider client={queryClient}>{children}</QueryClientProvider>
  )
}

test("my first test", async () => {
  const { result } = renderHook(() => useCustomHook(), {
    wrapper: createWrapper()
  })
}
```

これでコンポーネントツリーの全てのクエリーの初期設定を”リトライしない”ようにできます。これは明示的にリトライ指定せず`useQuery`を使用するときに限って機能することを知っておくのが重要です。初期設定がフォールバックとして使われるだけなので、5 回リトライさせたいクエリーがあるときはそれが優先されます。

### setQueryDefaults

この問題に対して私ができる最上の助言は、`useQuery`に直接このようなオプションを指定しないことです。可能な限り初期値を利用や上書きして、特定のクエリーに何か変更を加えたい時に限って[queryClient.setQueryDefaults](https://react-query.tanstack.com/reference/QueryClient#queryclientsetquerydefaults)を使ってください。

なので例えば`useQuery`にリトライを指定する代わりに

```tsx not-on-useQuery
const queryClient = new QueryClient()

function App() {
  return (
    <QueryClientProvider client={queryClient}>
      <Example />
    </QueryClientProvider>
  )
}

function Example() {
  // 🚨 テストのためにこの設定を上書きすることはできません！
  const queryInfo = useQuery({
    queryKey: ['todos'],
    queryFn: fetchTodos,
    retry: 5,
  })
}
```

このように設定します。

```tsx setQueryDefaults
const queryClient = new QueryClient({
  defaultOptions: {
    queries: {
      retry: 2,
    },
  },
})

// ✅ todosに限り5回リトライするようにします
queryClient.setQueryDefaults(['todos'], { retry: 5 })

function App() {
  return (
    <QueryClientProvider client={queryClient}>
      <Example />
    </QueryClientProvider>
  )
}
```

これで全てのクエリーが 2 回リトライするようになり、**_todos_**だけが 5 回リトライし、テストにおいて全てのクエリーのリトライを無効化する余地をまだ残しています 🙌。

### ReactQueryConfigProvider

もちろん、これは既知のクエリーキーに限って機能します。時にはコンポーネントツリーのサブセットに対していくつか設定を加えたいこともあると思います。v2 で、React Query はそのような用途にあった[ReactQueryConfigProvider](https://react-query-v2.tanstack.com/docs/api#reactqueryconfigprovider)を提供していました。v3 では以下のような数行のコードで同じことを実現できます。

```tsx ReactQueryConfigProvider
const ReactQueryConfigProvider = ({ children, defaultOptions }) => {
  const client = useQueryClient()
  const [newClient] = React.useState(
    () =>
      new QueryClient({
        queryCache: client.getQueryCache(),
        muationCache: client.getMutationCache(),
        defaultOptions,
      })
  )

  return (
    <QueryClientProvider client={newClient}>{children}</QueryClientProvider>
  )
}
```

[codesandbox の例](https://codesandbox.io/s/react-query-config-provider-v3-lt00f)でこれを実際に確認することができます。

## 常にクエリーを待つ

React Query はそれ自体非同期なので、フックを実行すると即座に結果が得られるわけではありません。大抵読み込み中で確認できるデータがない状態となります。react-hooks-testing-library による[非同期のユーティリティー](https://react-hooks-testing-library.com/reference/api#async-utilities)はこの問題を解決するさまざまな方法を提供しています。最もシンプルな例だと、クエリが成功した状態に遷移するまでただ待つことができます。

```tsx waitFor
const createWrapper = () => {
  const queryClient = new QueryClient({
    defaultOptions: {
      queries: {
        retry: false,
      },
    },
  })
  return ({ children }) => (
    <QueryClientProvider client={queryClient}>{children}</QueryClientProvider>
  )
}

test("my first test", async () => {
  const { result, waitFor } = renderHook(() => useCustomHook(), {
    wrapper: createWrapper()
  })

  // ✅ クエリが成功した状態に遷移するまで待つ
  await waitFor(() => result.current.isSuccess)

  expect(result.current.data).toBeDefined()
}
```

**更新**:  
[@testing-library/react v13.1.0](https://github.com/testing-library/react-testing-library/releases/tag/v13.1.0)から新しい[renderHook](https://testing-library.com/docs/react-testing-library/api/#renderhook)が利用できるようになりました。それ自体は`waitFor`ユーティリティを返さないので、代わりに[@testing-library/react から import](https://testing-library.com/docs/dom-testing-library/api-async/#waitfor)したものを使う必要があります。API が少し異なり、`boolean`を返すことができず、`Promise`が返されることを期待します。つまりコードを少し修正する必要があります。

```tsx new-render-hook
import { waitFor, renderHook } from '@testing-library/react'

test("my first test", async () => {
  const { result } = renderHook(() => useCustomHook(), {
    wrapper: createWrapper()
  })

  // ✅ waitForを期待するPromiseを返す
  await waitFor(() => expect(result.current.isSuccess).toBe(true))

  expect(result.current.data).toBeDefined()
}
```

## エラーコンソールを沈黙させる

初期設定につき、React Query はコンソールにエラーを出力します。全てのテストが 🟢 なのにコンソールに 🔴 が見えことになるので、テストにおいてこの点をとても邪魔なものだと思います。React Query はそのデフォルトの挙動を[ロガーを設定](https://react-query.tanstack.com/reference/setLogger)することで上書きできるので、私は普段からこのようにしています。

```tsx silence-errors
import { setLogger } from 'react-query'

setLogger({
  log: console.log,
  warn: console.warn,
  // ✅ コンソールにエラーを出さない
  error: () => {},
})
```

**更新**:  
v4 で`setLogger`は削除されました。その代わり`QueryClient`の prop としてカスタムのロガーを渡すことができます。

```tsx logger-prop
const queryClient = new QueryClient({
  logger: {
    log: console.log,
    warn: console.warn,
    // ✅ コンソールにエラーを出さない
    error: () => {},
  }
})
```

また、混乱を避けるため本番環境モードではエラーをログに記録しないようになりました。

## まとめ

私はこれら全てがよくまとまっている即席のリポジトリーをセットアップしました。mock-service-worker や react-testing-library、そして前述のラッパーを含んでいます。これは 4 つのテストを含んでいます - カスタムフックとコンポーネントの基本的な失敗と成功のテストです。[https://github.com/TkDodo/testing-react-query](https://github.com/TkDodo/testing-react-query) をご覧になってみてください。


React Queryのテスト


これは、[Dominik Dorfmeister 氏](https://tkdodo.eu/)のブログ記事である[Effective React Query Keys](https://tkdodo.eu/blog/effective-react-query-keys)を日本語訳してみたものです。

誤訳などあれば[Issue](https://github.com/makotot/makotot.dev/issues/new)や PR を頂けると幸いです。

---

[クエリのキー](https://react-query.tanstack.com/guides/query-keys)は React Query において非常に重要な核となる概念です。
これは、クエリーの依存に変化があった時、React Query が内部的にデータを正しくキャッシュしたり、自動的に再取得できるようにするために必要なことです。
そして、例えば、ミューテーションの後のデータ更新や、何かしらのクエリーをキャッシュ無効化する必要がある時、必要に応じて手動でクエリーのキャッシュとやりとりできるようにします。

より効果的にこのようなことを行う上で私がクエリーのキーをどのように構成しているかをお話しする前に、これら 3 つのポイントが意味することを確認してみましょう。

## データのキャッシュ

内部的には、クエリーのキャッシュは、キーがクエリーキーをシリアライズしたものであり、値がクエリーのデータにメタ情報を加えた、ただの JavaScript のオブジェクトです。
キーは、[決定論的な方法](https://react-query.tanstack.com/guides/query-keys#query-keys-are-hashed-deterministically)でハッシュ化されるので、オブジェクトを使うこともできます（トップレベルにおいてはキーが文字列か配列でなければいけないですが）。

最も重要な部分は、キーがクエリに対して**_ユニーク_**でなければいけないということです。React Query がキャッシュの中からキーに対するエントリーを見つけたら、それを使います。`useQuery`**_と_**`useInfiniteQuery`とで同じキーを使用できないことにも注意してください。結局のところ、ただ 1 つのクエリー**_キャッシュ_**があり、これら 2 つの間でデータは共有されるのです。無限のクエリーが”通常”のクエリーと根本的に異なる構造を持つため、これは好ましくありません。

```ts dont-mix-keys
useQuery({ queryKey: ['todos'], queryFn: fetchTodos })

// 🚨 これはうまくいきません
useInfiniteQuery({ queryKey: ['todos'], queryFn: fetchInfiniteTodos })

// ✅ 代わりに他のものを選びましょう
useInfiniteQuery({
  queryKey: ['infiniteTodos'],
  queryFn: fetchInfiniteTodos,
})
```

## 自動的な再取得

> クエリーは宣言的です。

これは強調しきれないほど**_とても_**重要な概念であり、また、”腑に落ちる”までしばらく時間を要するものです。ほとんどの人はクエリーを、特に再取得について、命令的な方法で考えます。

例えばクエリーが 1 つあり、何かデータを取得するとします。ボタンをクリックすると異なるパラメーターでデータを再取得しましょう。そうすると以下のような実装をよく目にします:

```tsx imperative-refetch
function Component() {
  const { data, refetch } = useQuery({
    queryKey: ['todos'],
    queryFn: fetchTodos,
  })

  // ❓ どのようにして再取得にパラメーターを渡すのでしょう ❓
  return <Filters onApply={() => refetch(???)} />
}
```

答えはこうです: **やらない。**

`refetch`はこのためのものではありません。**_同じパラメーターで_**再取得するためのものです。

React Query がキーの変化するたび常時自動的に再取得をトリガーするため、データを変更する何か**_状態_**を持つ場合、必要な唯一のことはクエリーキーにそれを含めることです。そのため、絞り込みを適用したい場合、**_クライアントステート_**を変更するだけです:

```tsx query-key-drives-the-query
function Component() {
  const [filters, setFilters] = React.useState()
  const { data } = useQuery({
    queryKey: ['todos', filters],
    queryFn: () => fetchTodos(filters),
  })

  // ✅ ローカルの状態を設定して、クエリーを”駆動”します
  return <Filters onApply={setFilters} />
}
```

`setFilters`によって引き起こされる再レンダリングは、React Query に異なるクエリーキーを渡します。

## 手動でのやりとり

クエリーキャッシュとの手動でのやりとりは、クエリーキーの構造が最も重要なものです。
[Query Filters](https://react-query.tanstack.com/guides/filters#query-filters)をサポートする[invalidateQueries](https://react-query.tanstack.com/reference/QueryClient#queryclientinvalidatequeries)や[setQueriesData](https://react-query.tanstack.com/reference/QueryClient#queryclientsetqueriesdata)のようなメソッドの多くがクエリーキーにあいまいな一致を許容します。

## 効果的な React Query のキー

これらの点は私の個人的な意見（実のところ、このブログの全てと同様）を反映しているので、クエリーキーを扱う時に絶対守らなければならないこととは考える必要がないことに留意してください。
この戦略はアプリケーションがより複雑になったとき最も効果的で、またとても良くスケールします。Todo アプリでは絶対に必要ありません 😁。

### コロケーション

[Kent C. Dodds](https://twitter.com/kentcdodds)氏による[Maintainability through colocation](https://kentcdodds.com/blog/colocation)をまだ読んだことがなければ、読んでみてください。私は`/src/utils/queryKeys.ts`に全てのクエリーキーを保持することが状況を良くするとは考えていません。以下のように、私はそれぞれのクエリーのそばにクエリーキーを持って、機能のディレクトリにコロケーションします:

```
- src
  - features
    - Profile
      - index.tsx
      - queries.ts
    - Todos
      - index.tsx
      - queries.ts
```

`queries`ファイルは React Query に関する全てを含むようにします。大抵カスタムフックだけをエクスポートし、クエリー関数とクエリーキーとがローカルに留まるようにします。

### 常に配列のキーを使用する

クエリーキーを文字列にもできますが、一貫性を持たせるため、私は常に配列にすることを好みます。React Query は内部的にいずれにしろ配列に変換します:

```ts always-use-array-keys
// 🚨 いずれにせよ['todos']に変換されます
useQuery({ queryKey: 'todos' })
// ✅
useQuery({ queryKey: ['todos'] })
```

**アップデート**: React Query v4 では、全てのキーが配列でなければいけません。

### 構成

クエリーキーは、最も一般的なものから最も具体的なものへと、間を適切な粒度のレベルで、構成します。ここでは、私が絞り込み可能なリスト、並びに詳細の表示が可能な TODO リストをどのように構成するかを示します:

```
['todos', 'list', { filters: 'all' }]
['todos', 'list', { filters: 'done' }]
['todos', 'detail', 1]
['todos', 'detail', 2]
```

このような構成により、`['todos']`と紐づく全ての TODO、全てのリストか全ての詳細、正確なキーを知っていれば特定の 1 つをキャッシュ無効化することもできます。必要に応じて全てのリストを対象にできるので、[ミューテーションのレスポンスからの更新](https://react-query.tanstack.com/guides/updates-from-mutation-responses)がより柔軟になります:

```tsx updates-from-mutation-responses
function useUpdateTitle() {
  return useMutation({
    mutationFn: updateTitle,
    onSuccess: (newTodo) => {
      // ✅ TODOの詳細を更新
      queryClient.setQueryData(['todos', 'detail', newTodo.id], newTodo)

      // ✅ このTODOを含む全てのリストを更新
      queryClient.setQueriesData(['todos', 'list'], (previous) =>
        previous.map((todo) => (todo.id === newTodo.id ? newtodo : todo))
      )
    },
  })
}
```

リストと詳細の構成が大きく異なるのであればうまくいかないかもしれませんが、代わりに、全てのリストをただキャッシュ無効化することももちろん可能です:

```tsx invalidate-all-lists focus=7:8
function useUpdateTitle() {
  return useMutation({
    mutationFn: updateTitle,
    onSuccess: (newTodo) => {
      queryClient.setQueryData(['todos', 'detail', newTodo.id], newTodo)

      // ✅ 全てのリストをキャッシュ無効化
      queryClient.invalidateQueries({ queryKey: ['todos', 'list'] })
    },
  })
}
```

例えば URL から絞り込みするような、現在どのリストにいるか分かり、それゆえ正確なクエリーキーが構築できる場合、この 2 つのメソッドを組み合わせてリストに対して`setQueryData`を呼び、その他全てをキャッシュ無効化することもできます。

```tsx combine focus=10:19
function useUpdateTitle() {
  // URLに保持している現在のフィルターを返すカスタムフックをイメージしてください
  const { filters } = useFilterParams()

  return useMutation({
    mutationFn: updateTitle,
    onSuccess: (newTodo) => {
      queryClient.setQueryData(['todos', 'detail', newTodo.id], newTodo)

      // ✅ 即座に現在のリストを更新
      queryClient.setQueryData(['todos', 'list', { filters }], (previous) =>
        previous.map((todo) => (todo.id === newTodo.id ? newtodo : todo))
      )

      // 🥳 全てのリストをキャッシュ無効化しつつ、アクティブなものを再取得しない
      queryClient.invalidateQueries({
        queryKey: ['todos', 'list'],
        refetchActive: false,
      })
    },
  })
}
```

**アップデート**: v4 で、`refetchActive`は`refetchType`に置き換わっています。上記の例だと何も再取得したくないので、`refetchType: 'none'`となります。

### クエリーキーのファクトリーを使用する

上述の例で、たくさんのクエリーキーを手動で記述していることに気づいたでしょう。これは間違いの元であるだけでなく、例えばもう 1 段階**_他の_**粒度のキーを追加したくなった場合のような、将来の変更を難しくもします。

私が機能ごとのクエリーキーのファクトリーを推奨する理由がここにあります。これは、カスタムフックで利用できる、ただのエントリーとクエリーキーを生み出す関数のオブジェクトです。
上述の構造の例だと、このようになります:

```ts
const todoKeys = {
  all: ['todos'] as const,
  lists: () => [...todoKeys.all, 'list'] as const,
  list: (filters: string) => [...todoKeys.lists(), { filters }] as const,
  details: () => [...todoKeys.all, 'detail'] as const,
  detail: (id: number) => [...todoKeys.details(), id] as const,
}
```

各階層が関連していながらも独立してアクセスできるようになっていて、とても柔軟です:

```tsx examples
// 🕺 TODOの機能に関連する全てを削除
queryClient.removeQueries({ queryKey: todoKeys.all })

// 🚀 全てのリストのキャッシュを無効化
queryClient.invalidateQueries({ queryKey: todoKeys.lists() })

// 🙌 1つのTODOをプリフェッチ
queryClient.prefetchQueries({
  queryKey: todoKeys.detail(id),
  queryFn: () => fetchTodo(id),
})
```


効果的なReact Queryのキー


これは、[Dominik Dorfmeister 氏](https://tkdodo.eu/)のブログ記事である[Inside React Query](https://tkdodo.eu/blog/inside-react-query)を日本語訳してみたものです。

誤訳などあれば[Issue](https://github.com/makotot/makotot.dev/issues/new)や PR を頂けると幸いです。

---

React Query が内部的にどのように機能しているのか、最近よく聞かれるようになりました。再レンダリングするタイミングををどうやって検知しているのか？ 重複をどうやって排除するのか？ どうやってフレームワークに依存しないようになっているのか？

いずれもとても良い質問です。では、私たちの愛する非同期状態管理ライブラリを細かく確認して、`useQuery`を呼んだら何が起きるのかを調査しましょう。

構造を理解するためには最初から始めなければいけません。

## QueryClient

![QueryClient with defaultOptions holds the QueryCache](/images/content/inside-react-query-translation-ja/queryclient.png "defaultOptionsによるQueryClientがQueryCacheを保持")

全ての始まりは`QueryClient`です。これは、恐らくアプリケーション起動時に、インスタンスを生成するクラスで、`QueryClientProvider`を通してどこでも利用可能になるものです。

```js query-client-provider
import { QueryClient, QueryClientProvider } from '@tanstack/react-query'

// ⬇️ クライアントを生成
const queryClient = new QueryClient()

function App() {
  return (
    // ⬇️ クライアントを配布
    <QueryClientProvider client={queryClient}>
      <RestOfYourApp />
    </QueryClientProvider>
  )
}
```

`QueryClientProvider`は[React Context](https://beta.reactjs.org/reference/react/useContext) を利用してアプリケーション全体に`QueryClient`を配布します。
クライアント自体は安定した値で、1 度だけ作られる（[うっかり幾度も再生成しないよう](https://tkdodo.eu/blog/react-query-fa-qs#2-the-queryclient-is-not-stable)に注意してください）ので、Context を利用するのに最適なケースです。
アプリケーションを再レンダリング**_せずに_**、クライアントに`useQueryClient`を通してアクセスできるようにするだけです。

## キャッシュを格納する容器

あまり知られてないことだと思いますが、`QueryClient`自体はあまり多くのことを行いません。`QueryCache`や`MutationCache`のコンテナーであり、`new QueryClient`を生成するとき自動的に生成されます。

また、全てのクエリやミューテーションに設定できるいくつかの初期値を持っていて、キャッシュを操作するための便利なメソッドを提供します。ほとんどのケースにおいては、キャッシュと直接やりとりすることは**_ありません_**。
やりとりする場合に`QueryClient`を通してアクセスします。

## QueryCache

さて、クライアントでキャッシュを扱えるようになりました。キャッシュとは何でしょうか？

![QueryCache consists of Queries and syncs with Persisters](/images/content/inside-react-query-translation-ja/querycache.png "QueryCacheはQueryで構成されて、Persisterと同期する")

簡単に言うと、 `QueryCache` は、**queryKeys** をしっかりとシリアライズしたもの（**queryKeyHash** ）によるキーと、 `Query`クラスのインスタンスによる値とのインメモリーのオブジェクトです。

デフォルトの状態の React Query がインメモリー**_だけ_**に保存して、それ以外のどこにも保存しないということを理解するのが、私は重要だと思います。ブラウザのページを再読み込みしたら、キャッシュはなくなります。
localstorage のような外部ストレージにキャッシュを書き込みたいときは、[persister](https://tanstack.com/query/v4/docs/react/plugins/persistQueryClient)について一読ください。

## Query

![Query informs Observers](/images/content/inside-react-query-translation-ja/query.png "QueryはObserverに通知する")

キャッシュにはクエリがあり、`Query`にロジックの大部分が集まります。クエリ（自身のデータや、ステータスか直近のフェッチがいつ発生したかのようなメタ情報）に関する全ての情報が含まれているだけでなく、クエリ機能の実行も担っていて、リトライやキャンセル、重複削除のロジックも持っています。

これは、実現不可能な状態に陥らないように、内部的に**_ステートマシーン_**を持ちます。例えば、すでにフェッチされている中でもクエリ機能を呼ぶ必要があれば、そのフェッチを重複削除できたりします。クエリがキャンセルされたら、以前の状態に戻ります。

何よりも重要なこととして、クエリはクエリデータに対して**_誰が_**興味を持っているかを把握していて、全ての変更に関して`Observers`へ伝えることができます。

## QueryObserver

![Observer is created by useQuery and informs the component about updates](/images/content/inside-react-query-translation-ja/queryobserver.png "ObserverはuseQueryによって生成されて、更新をコンポーネントに知らせる")

オブザーバーは、`Query`とコンポーネントとの間の接着剤です。`Observer`は`useQuery`が呼ばれたときに生成され、常に 1 つのクエリだけを購読します。`useQuery`に`queryKey`を渡さなければならないのは、このためです。 😉

`Observer`が行うのはこれだけではありません。最適化の大部分がここで行われます。`Observer`は、コンポーネントが使用している`Query`のプロパティーがどれかを知っているので、無関係の変更を通知する必要がありません。
例として、`data`フィールドだけを使っているのであれば、バックグラウンドで再度フェッチが行われて`isFetching`に変更があっても、コンポーネントの再レンダリングは不要です。

さらに`Observer`毎に**_selector_**オプションを持ち、`data`フィールドのどこに関心があるかを決定できます。  以前、[#2: React Query Data Transformations](https://tkdodo.eu/blog/react-query-data-transformations#3-using-the-select-option)でこの最適化について書きました。
`stealTime`の類やインターバルでのフェッチのようなタイマーのほとんどもまたオブザーバー層で発生します。

## 活性なクエリと非活性なクエリ

`Observer`を持たない`Query`は、**_非活性な_**クエリと呼ばれます。どのコンポーネントからも使われていませんが、キャッシュにはまだあります。React Query DevTools を見るとき、グレイアウトした非活性のクエリを目にすることがあるでしょう。
左の数値はクエリをサブスクライブしている`Observer`の数を示します。

![Devtools where one query has 2 observers and another one has 0](/images/content/inside-react-query-translation-ja/devtools.png "2つのオブザーバーを持つクエリと1つもオブザーバーを持っていないクエリのDevtools")

## 全体像

![Full overview of the architecture](/images/content/inside-react-query-translation-ja/architecture.png "アーキテクチャの全体像")

まとめると、ほとんどのロジックがフレームワークに依存しない Query Core の部分にあります: `QueryClient`、`QueryCache`、`Query`、`QueryObserver`などが全てここにあります。

そのため、新しいフレームワークに対するアダプターをつくることは非常に簡単です。基本的に必要となるのは、`Observer`を生成して、購読して、`Obsever`から通知があればコンポーネントを再レンダリングする方法です。
[react](https://github.com/TanStack/query/blob/9d9aea5fb12eb89dec54c619845b3d226b53cf2b/packages/react-query/src/useBaseQuery.ts#L33-L115)や[solid](https://github.com/TanStack/query/blob/9579dd893656d0a4a7ac0207a204d4b3735c329d/packages/solid-query/src/createBaseQuery.ts#L33-L131)の`useQuery`のアダプターは、いずれも 100 行程度のコードです。

## コンポーネントの視点から

最後に、異なる視点から流れを見ましょう。コンポーネントから始まる流れです。

![flow from component mounting over fetching data to rendering it](/images/content/inside-react-query-translation-ja/flow.png "コンポーネントのマウントからデータのフェッチ、レンダリングまでの流れ")

- コンポーネントが**_マウント_**されたら`useQuery`が呼ばれて`Observer`が生成されます。
- `Observer`は`QueryCache`にある`Query`を購読します。
- サブスクリプションは、（まだ無ければ）`Query`の生成のトリガーとなるか、データが古いと判断されたときにバックグラウンドで再度フェッチするトリガーとなります。
- フェッチが開始されると`Query`の状態が変わるので、`Observer`はその変化を検知します。
- `Observer`はいくつかの最適化を行い、新しい状態をレンダリングする更新をコンポーネントに通知します。
- `Query`の実行が完了したら、`Observer`にそれを知らせます。

これは考えられるさまざまな流れの中の**_1 つにすぎない_**ことに注意してください。理想的な状態は、コンポーネントがマウントされたとき、既にデータがキャッシュにあることです。
より詳細には、[#17: Seeding the Query Cache](https://tkdodo.eu/blog/seeding-the-query-cache) を一読ください。

全ての流れに共通するのは、ロジックの大半が React（もしくは Solid や Vue など）の外で発生して、ステートマシーンからの全ての更新が`Observer`にまで伝わって、`Observer`がコンポーネントにまで伝えるべきかを決定します。


React Queryの内部


これは、[Kent C. Dodds 氏](https://kentcdodds.com/)のブログ記事である[Colocation](https://kentcdodds.com/blog/colocation)を日本語訳してみたものです。

誤訳などあれば[Issue](https://github.com/makotot/makotot.dev/issues/new)や PR を頂けると幸いです。

---

誰もがコードベースをメンテナンスしやすい状態に保ちたいので、コードベース（もしくはその一角）をメンテナンスしやすく理解しやすくなるように最善の努力を持って始めます。
時が経って、コードベースが大きくなるにつれて、依存関係（JS、CSS、画像など）を管理するのは、より一層難しくなります。
プロジェクトが大きくなるにつれて、コードベースが"チーム固有の知識"（あなたや他の数名に限られた知識）になってしまうことは往々にしてあり、
このような知識が”技術的負債”（言葉の正確性は[ともかく](https://twitter.com/ryanflorence/status/747983065738153985)）の原因となります。

私は、コードベースを私自身（筆者）だけではなくチームメンバー、未来のメンテナー、そして半年後の自分自身にも扱いやすい状態に保ちたいです。これがコードベースにおける目指すべき状態であることについて誰もが同意するものと、私は考えています。
その実現のために、さまざまなツールやテクニックが存在します。

## コードコメントについて話しましょう

私は、コメントを書く（べき）かについてだったり、コメントがどうあるべきか（予想外のことをする理由をコメントで記述して、後から来る人に予想外なコードや奇妙なコードができあがった決定について理解できるようにする）について議論したくありません。
（OK、少しは話したかったのかもしれません）。その代わりに、コードコメントをどこに配置するかについて焦点を当てたいと思います。私たちは一般的に、可能な限りコメントが説明しているコードに近い場所に”コロケーションします”。

異なる形にしたらどうか、少し考えてみてください。このようなコードコメントを完全に別のファイルへ配置したらどうでしょうか。大量の **`DOCUMENTATION.md`** や **`docs/`** ディレクトリが `src/`ディレクトリにマッピングされます。
面白そうですか？そうですね、私も面白く感じません。説明するコードに対してコメントをコロケーションしないことで、いくつかの深刻な問題に直面します。

- **メンテナビリティ**: （今以上に）より早く同期が取れず、古い状態になりやすいでしょう。対応する **`docs/`** のファイルを更新することなく **`src/`** のファイルを移動したり、削除したりするようになるでしょう。
- **適用性**: **`src/`** のコードを見ている人が、**`src/`** のファイルに対する **`docs/`** のファイルがあることに気付かず、 **`docs/`** の重要なコメントを見逃したり、コメントを書かなかったりするかもしれません。
- **使いやすさ**: このような設定では、ある場所から別のところへのコンテキストスイッチが難しいでしょう。ファイルが複数の場所で扱われると、コンポーネントをメンテナンスするのに必要なものを把握することが難しくなります。

確かにこのようなコードコメントのスタイルの規約を作ることはできますが、そうしたいでしょうか？ コメントは、説明するコードの近くにコロケーションしておく方がよりシンプルではないでしょうか？

## それがどうしたというのか？

さて、おそらくあなたはこう思っていることでしょう: ”そうですね、だから皆 **`docs/`** のようなものではなくてコードとコメントをコロケーションするようにしています。それは分かりきったことです。言いたいことは何なのですか？” と。
私が主張したいのは、コロケーションの利点はどこにでもあるということです。

### HTML/View

HTML を例にとってみましょう。コメントのコロケーションの利点はテンプレートに対しても全て適用されます。React のようなモダンなフレームワークの以前は、ビューロジックやビューのテンプレートを完全に分離していました。
この場合、上述の問題が発生します。例えば React や Vue においてはこれらを **完全に同じファイルに** 記述することが、最近ではより一般的になっています。Angular では、テンプレートファイルを同じファイルではなくても、少なくとも関連するファイルのすぐ近くに置きます。

### CSS

この概念について、よく当てはまるのが CSS です。CSS-in-JS（ファンタスティックですね）のメリットについてここで議論するつもりはありませんが、得られるものはこの世のものとは思えません。
[詳しくはこちらを確認してください](https://medium.com/seek-blog/a-unified-styling-language-d0c208de2660) 。

### テスト

ユニットテストについてもファイルのコロケーションの考え方が良く当てはまります。 **`src/`** ディレクトリと **`src/`** ディレクトリをミラーすることを試みたユニットテストのファイルでいっぱいの **`test/`** ディレクトリとを持つプロジェクトは、
よくあるものでしょうか？ 上述の落とし穴がここにもあるのです。私はユニットテストを全く同じファイルに記述しないかもしれませんが、興味深いアイディアとして排除しないでおきます（実装は読者の方にお任せします）。

よりメンテナンスしやすいコードベースを実現するために、テスト対象のファイルとテストのファイルをコロケーションするべきです。新しい人（もしくは半年後の自分自身）がコードを読むとき、
すぐにそのモジュールがテストされていることを見て取れて、そのモジュールの理解の助けとしてテストのファイルを利用できます。変更があれば、その変更に関連するテストの更新（追加 / 削除 / 修正）のリマインドとなります。

### 状態

アプリケーション / コンポーネントの状態も同様の効果を得られます。その状態を反映する UI から切り離され / 間接的になればなるほど、メンテナンスは難しくなります。状態をローカライズすることはメンテナビリティの利点が得られるだけではなく、
アプリケーションのパフォーマンスの改善にもつながります。アプリケーションのコンポーネントツリーの一角で起こる状態の変化は、ツリーの最上位での状態の変化よりも少ないコンポーネントの再レンダリングで済みます。状態をローカライズしましょう。

### "再利用性のある"ユーティリティのファイル

"ユーティリティ"ファイルや関数にも同様です。あるコンポーネントを書いていて、それ自体を関数として抽出できるかたまりを見つけたと、イメージしてください。
あなたはそれを抽出して考えます: "うーん、、、これは多くの人に使ってもらえるんじゃないか"と。そして、それをアプリケーションの **`utils/`** ディレクトリに移して、人生を歩んでいきます。

しばらくして、コンポーネントは削除されましたが、ユーティリティは見えなくなって、より広範囲で利用されているものと削除した人が考えたため、残ることになりました（そのテストとともに）。
その後幾年も、エンジニアは、全くもって不要であることに気づくことなく、その関数とテストを動かし続けることを懸命に努力することになります。無駄な労力と認知負荷です。

もし、関数を使われるファイル内に直接残しておけば、話は全く異なるものになるでしょう。私が言いたいのは、複雑なユーティリティ関数をわざわざテストしないで（してください）ということではなく、
利用される場所に近づけて置いておくと問題を回避する助けになるということです。

> そしてお願いだから、[この ESLint のルール](https://github.com/jsx-eslint/eslint-plugin-react/blob/e6b4c33a1db4cc94c3e9223b09fb92b1dbddc00d/docs/rules/no-multi-comp.md) とそれに近似するルールを削除してください。

## 原則

コロケーションの概念はこの基本的な原則に集約されます:

> 可能な限り関連性が高いものの近くにコードを置いてください。

こうも言えます: "一緒に変化するものは、合理的な範囲で近くに置くべきです。"と。（ [Dan Abramov](https://twitter.com/dan_abramov)氏がかつて私にこのような話をしました。）

## （より）分かりやすいオープンソース

上述の問題を避ける一方で、このようにプロジェクトを構成する利点が他にもあります。あるコンポーネントをオープンソースのプロジェクトに変換するのは、大抵、フォルダーを他のプロジェクトへコピー / ペーストして npm に公開するのと同じくらい簡単です。
そして、プロジェクトにインストールして、 **`require`** / **`import`** を更新するだけでもう大丈夫です。

## 例外

システムの一部かもしくは全体にまたがるドキュメントや、ものがどうやって統合されるかについてのドキュメントは、確かに良い議論の対象でしょう。そして、コンポーネントを横断したインテグレーションもしくは E2E のテストをどこに置くべきでしょう？
**_これらは例外だと考えるかもしれません_** が、実のところ先ほどの原則によく合致します。

ユーザーの認証に関するアプリケーションの部分があると仮定して、そのフローについてドキュメントを持ちたいとしたら、ユーザーの認証に関する全てのモジュールを内包するフォルダーに **_README.md_** を置きます。
このフローにインテグレーションテストを必要とするのであれば、同じフォルダーにテストのファイルを置きます。

E2E テストに関しては、プロジェクトの最上位に置くのがより合理的です。プロジェクト自体に留まらず、システムの他の部分も範囲となるので、別のディレクトリに置くことが合理的だと考えられます。
**`src/`** のファイルにマッピングされないのです。実際、E2E テストは **`src/`** がどのように構成されるか全く気にしません。 **`src/`** ディレクトリのリファクタリングやファイルの移動は、E2E テストへの変更を必要としないようにあるべきです。

## 結論

ここで私たちがゴールとするのは、可能な限りメンテナンスが容易なソフトウェアを開発することです。コメントをコロケーションすることで得られる **メンテナビリティ** 、 **適用性** 、 **使いやすさ** の利点は、
他のものをコロケーションすることでも同じように得られます。試したことがなければ、試してみることをおすすめします。

追伸: "関心の分離"に反することが気がかりであれば、 [こちらの講演](https://youtu.be/x7cQ3mrcKaY) を視聴して、その意味を問い直すことをおすすめします  😀。

さらに追伸: 画像や他のリソースにもよく適用できることもまた書き留めておきます。[webpack](https://webpack.js.org/) のようなツールを使っている場合、このようなリソースをコロケーションするのは申し分なく簡単になります。
実際のところ、私の意見ではこれが webpack の核となる提供価値の 1 つだと思います。


コロケーション


これは、[Kent C. Dodds 氏](https://kentcdodds.com/)のブログ記事である[AHA Testing 💡](https://kentcdodds.com/blog/aha-testing)を日本語訳してみたものです。

誤訳などあれば[Issue](https://github.com/makotot/makotot.dev/issues/new)や PR を頂けると幸いです。

---

[AHA プログラミング原則](https://kentcdodds.com/blog/aha-programming)は”Avoid Hasty Abstraction（性急な抽象化を避けよ）”の略です。私には、メンテナブルなテストを書く上でこれをどのように適用するかということの具体的な思いがあります。
私が実際に見てきたテストのほとんどが抽象の分布の片方に偏ったものでした：ANA（”Absolutely No Abstraction” - 全く抽象化しない）か完全に DRY（Don't Repeat Yourself - 繰り返しを避ける）か。（ANA はたった今作りました。）

<div style={{width: '100%', marginTop: 10, marginBottom: 40, overflow: "auto"}}>
  <div
    style={{
      width: '100%',
      display: 'flex',
      justifyContent: 'space-between',
      fontSize: '1.5em',
      textAlign: 'center',
      lineHeight: 1.2,
      marginBottom: 4,
    }}
  >
    <div style={{color: 'rgb(94, 49, 220)'}}>
      <strong style={{display: 'block'}}>ANA</strong>
      <small style={{display: 'block', fontSize: '0.5em'}}>{`(Absolutely No Abstraction)`}</small>
    </div>
    <div style={{color: 'rgb(71,67,220)'}}>
      <strong style={{display: 'block'}}>AHA</strong>
      <small style={{display: 'block', fontSize: '0.5em'}}>{`(Avoid Hasty Abstraction)`}</small>
    </div>
    <div style={{color: 'rgb(49, 85, 220)'}}>
      <strong style={{display: 'block'}}>DRY</strong>
      <small style={{display: 'block', fontSize: '0.5em'}}>{`(Don't Repeat Yourself)`}</small>
    </div>
  </div>
  <div
    style={{
      width: '100%',
      height: 20,
      backgroundImage:
        'linear-gradient(-213deg, rgb(94, 49, 220) 0%, rgb(49, 85, 220) 100%)',
    }}
  />
  <div
    style={{
      marginTop: 10,
      color: 'rgb(71,67,220)',
      background:
        'linear-gradient(-213deg, rgb(94, 49, 220) 0%, rgb(49, 85, 220) 100%)',
      WebkitBackgroundClip: 'text',
      WebkitTextFillColor: 'transparent',
      display: 'flex',
      justifyContent: 'space-between',
      fontSize: '1.8em',
    }}
  >
    <strong>T</strong>
    <strong>h</strong>
    <strong>e</strong>
    <strong />
    <strong>S</strong>
    <strong>p</strong>
    <strong>e</strong>
    <strong>c</strong>
    <strong>t</strong>
    <strong>r</strong>
    <strong>u</strong>
    <strong>m</strong>
    <strong />
    <strong>o</strong>
    <strong>f</strong>
    <strong />
    <strong>A</strong>
    <strong>b</strong>
    <strong>s</strong>
    <strong>t</strong>
    <strong>r</strong>
    <strong>a</strong>
    <strong>c</strong>
    <strong>t</strong>
    <strong>i</strong>
    <strong>o</strong>
    <strong>n</strong>
  </div>
</div>

抽象化の分布の中間のスイートスポットを見つけることがメンテナブルなテストを開発する鍵となります。

## ANA テスト

私が見てきたテストにおける”全く抽象化しない”最も良い例は[ExpressJS のルートのハンドラー](https://expressjs.com/en/guide/routing.html)です。
”ANA がテストに向いていない”と私が言うことが何を意味しているかを理解してもらうために、典型的なテストファイルを用意してそのコードベースとテストをメンテナンスするふりをしてみましょう。
このルートがどのように動作するかを理解していることが重要です。あなたは、何か壊してしまわないようにするためのテストがあることで安心します。それであなたはルートハンドラのニュアンスを理解するためにテストを利用することにします。

このテストを読んで、2 つの間の微妙な差異を理解してみましょう。

> 時間をかけ過ぎないように。。。

```js
import * as blogPostController from '../blog-post'

// データベース用のアプリケーション全体でのモックを読み込みます。
// これはANNA（Almost Absolutely No Abstraction - ほぼ全く抽象化しない）を
// 意味するかもしれませんが、データベースのモックの全てをこのブログ記事に
// 書きたくありません 😅
jest.mock('../../lib/db')

test('lists blog posts for the logged in user', async () => {
  const req = {
    locale: {
      source: 'default',
      language: 'en',
      region: 'GB',
    },
    user: {
      guid: '0336397b-e29d-4b63-b94d-7e68a6fa3747',
      isActive: false,
      picture: 'http://placehold.it/32x32',
      age: 30,
      name: {
        first: 'Francine',
        last: 'Oconnor',
      },
      company: 'ACME',
      email: 'francine.oconnor@ac.me',
      latitude: 51.507351,
      longitude: -0.127758,
      favoriteFruit: 'banana',
    },
    body: {},
    cookies: {},
    query: {},
    params: {
      bucket: 'photography',
    },
    header(name) {
      return {
        Authorization: 'Bearer TEST_TOKEN',
      }[name]
    },
  }
  const res = {
    clearCookie: jest.fn(),
    cookie: jest.fn(),
    end: jest.fn(),
    locals: {
      content: {},
    },
    json: jest.fn(),
    send: jest.fn(),
    sendStatus: jest.fn(),
    set: jest.fn(),
  }
  const next = jest.fn()

  await blogPostController.loadBlogPosts(req, res, next)

  expect(res.json).toHaveBeenCalledTimes(1)
  expect(res.json).toHaveBeenCalledWith({
    posts: expect.arrayContaining([
      expect.objectContaining({
        title: 'Test Post 1',
        subtitle: 'This is the subtitle of Test Post 1',
        body: 'The is the body of Test Post 1',
      }),
    ]),
  })
})

test('returns an empty list when there are no blog posts', async () => {
  const req = {
    locale: {
      source: 'default',
      language: 'en',
      region: 'GB',
    },
    user: {
      guid: '0336397b-e29d-4b63-b94d-7e68a6fa3747',
      isActive: false,
      picture: 'http://placehold.it/32x32',
      age: 30,
      name: {
        first: 'Francine',
        last: 'Oconnor',
      },
      company: 'ACME',
      email: 'francine.oconnor@ac.me',
      latitude: 31.230416,
      longitude: 121.473701,
      favoriteFruit: 'banana',
    },
    body: {},
    cookies: {},
    query: {},
    params: {
      bucket: 'photography',
    },
    header(name) {
      return {
        Authorization: 'Bearer TEST_TOKEN',
      }[name]
    },
  }
  const res = {
    clearCookie: jest.fn(),
    cookie: jest.fn(),
    end: jest.fn(),
    locals: {
      content: {},
    },
    json: jest.fn(),
    send: jest.fn(),
    sendStatus: jest.fn(),
    set: jest.fn(),
  }
  const next = jest.fn()

  await blogPostController.loadBlogPosts(req, res, next)

  expect(res.json).toHaveBeenCalledTimes(1)
  expect(res.json).toHaveBeenCalledWith({
    posts: [],
  })
})
```

違いを見つけられましたか？そう！最初の方では記事を見つけることを想定して、2 つ目の方ではそうではないことを想定しています。いいですね！よくできました。でも、、、何が原因でしょうか？
なぜ`blogPostController.loadBlogPosts(req, res, next)`が`res.json`で最初の方はブログ記事を返して 2 つ目ではそうならないのでしょうか？

もし分からなくても後でお伝えするので、気を悪くしたり心配したりしないでも大丈夫です。もし分かるのだとしたらあなたは恐らく[”ウォーリーを探せ”](https://en.wikipedia.org/wiki/Where%27s_Wally%3F)が得意で、
そしてそれが私の主張したいことです。このようなテストはテストを理解してメンテナンスすることを必要以上に難しくします。

では 1 つのファイルにこのようなテストが 20 個あることを想像してください。恐ろしくありませんか？そうです、とても酷いです。そのようなテストを 1 度も見たことがありませんか？あなたはとても幸運です！
私は幾度となく目にしておきました。その経緯はこのようなものです：

1. エンジニアのジョーがチームにジョインします
1. ジョーはテストを追加する必要に迫られます
1. ジョーは必要としたものによく似た以前からあるテストをコピーして、ユースケースに合わせて修正します
1. レビュアーはテストが通ることを確認して、ジョーが会話を理解していると考えます
1. PR がマージされます

これがリトマス試験紙です：

> 2 つの類似したテストのアサーションの違いを判断するのはどれくらい簡単で、その違いが何から生じますか？

全く抽象化しないテストはこれを非常に難しくします。

## DRY テスト

今は`DRY`なテストの良い例を出す時間がありません。何にでも`DRY`を適用するとこのようなプロセスのためにメンテナンスが難しくなっていくことがよくあるのを知ってください：

1. エンジニアのジョーがチームにジョインします
1. ジョーはテストを追加する必要に迫られます
1. ジョーは基本的に必要としたものによく似た以前からあるテストをコピーして、状況に合わせてテストのユーティリティーに他の`if`文を追加します
1. レビュアーはテストが通ることを確認して、ジョーが会話を理解していると考えます
1. PR がマージされます

私が DRY なテストでよく目にするもう 1 つのものは、`describe`と`it`のネスト + `beforeEach`の濫用です。ネストしてテスト間で変数を共有すればするほど、ロジックを追いかけるのが困難になります。
[Test Isolation with React](https://kentcdodds.com/blog/test-isolation-with-react)においてこの問題について少し書いてあるので読んでみるといいかもしれません。

## AHA テスト

最初のテストは確実に抽象化のための悲鳴を上げています（これは AHA プログラミングの指針となるものです）。そこで、思慮深く抽象化したものを書いてみましょう。これらのテストで何が違いを生んでいるかを考えてください：

```js
import * as blogPostController from '../blog-post'

// データベース用のアプリケーション全体でのモックを読み込みます。
jest.mock('../../lib/db')

function setup(overrides = {}) {
  const req = {
    locale: {
      source: 'default',
      language: 'en',
      region: 'GB',
    },
    user: {
      guid: '0336397b-e29d-4b63-b94d-7e68a6fa3747',
      isActive: false,
      picture: 'http://placehold.it/32x32',
      age: 30,
      name: {
        first: 'Francine',
        last: 'Oconnor',
      },
      company: 'ACME',
      email: 'francine.oconnor@ac.me',
      latitude: 51.507351,
      longitude: -0.127758,
      favoriteFruit: 'banana',
    },
    body: {},
    cookies: {},
    query: {},
    params: {
      bucket: 'photography',
    },
    header(name) {
      return {
        Authorization: 'Bearer TEST_TOKEN',
      }[name]
    },
    ...overrides,
  }

  const res = {
    clearCookie: jest.fn(),
    cookie: jest.fn(),
    end: jest.fn(),
    locals: {
      content: {},
    },
    json: jest.fn(),
    send: jest.fn(),
    sendStatus: jest.fn(),
    set: jest.fn(),
  }
  const next = jest.fn()

  return {req, res, next}
}

test('lists blog posts for the logged in user', async () => {
  const {req, res, next} = setup()

  await blogPostController.loadBlogPosts(req, res, next)

  expect(res.json).toHaveBeenCalledTimes(1)
  expect(res.json).toHaveBeenCalledWith({
    posts: expect.arrayContaining([
      expect.objectContaining({
        title: 'Test Post 1',
        subtitle: 'This is the subtitle of Test Post 1',
        body: 'The is the body of Test Post 1',
      }),
    ]),
  })
})

test('returns an empty list when there are no blog posts', async () => {
  const {req, res, next} = setup()
  req.user.latitude = 31.230416
  req.user.longitude = 121.473701

  await blogPostController.loadBlogPosts(req, res, next)

  expect(res.json).toHaveBeenCalledTimes(1)
  expect(res.json).toHaveBeenCalledWith({
    posts: [],
  })
})
```

お分かり頂けたでしょうか？最初のテストと 2 つ目のテストとの違いは何でしょうか？最初のテストではユーザーがロンドンにいて、2 つ目のテストではユーザーが上海にいます！
うーん、同僚が私たちは位置情報に基づくブログプラットフォームに取り組んでいると言ってくれたら良かったのに（ちょっと、これは面白いプロダクトのアイディアですよね 🤔）。

少しの心がけで抽象化することで、入力と出力の違いで何が重要かより明確になって、より意味のあるメンテナンスしやすいテストとなりました。

## React の AHA テスト

React では、私はここでの`setup`関数のように振る舞う`renderFoo`関数を用意することが時々あります。以下が簡単な例です：

```tsx
import * as React from 'react'
import {render, screen} from '@testing-library/react'
import userEvent from '@testing-library/user-event'
import LoginForm from '../login-form'

function renderLoginForm(props) {
  render(<LoginForm {...props} />)
  const usernameInput = screen.getByLabelText(/username/i)
  const passwordInput = screen.getByLabelText(/password/i)
  const submitButton = screen.getByText(/submit/i)
  return {
    usernameInput,
    passwordInput,
    submitButton,
    changeUsername: value => userEvent.type(usernameInput, value),
    changePassword: value => userEvent.type(passwordInput, value),
    submitForm: () => userEvent.click(submitButton),
  }
}

test('submit calls the submit handler', () => {
  const handleSubmit = jest.fn()
  const {changeUsername, changePassword, submitForm} = renderLoginForm({
    onSubmit: handleSubmit,
  })
  const username = 'chucknorris'
  const password = 'ineednopassword'
  changeUsername(username)
  changePassword(password)
  submitForm()
  expect(handleSubmit).toHaveBeenCalledTimes(1)
  expect(handleSubmit).toHaveBeenCalledWith({username, password})
})
```

> 注意：これを使用するテストが 1 つのファイルにおいて 2 つか 3 つしかなく短いものである場合、私はこれを時期早々の抽象化だと考えるでしょう。ただし、テストしているのがいくつかの微妙な差異を持つ場合（例えばエラーの状態のようなもの）、
> このような抽象化は素晴らしいものとなります。

## ネスト

[Avoid Nesting in Tests](https://kentcdodds.com/blog/avoid-nesting-when-youre-testing)を一度読んでみてください。

## jest-in-case と test.each

純粋な関数に対してテストを書いている場合、大抵最もテストしやすいものなのでついています。非常に明確な形で入力と出力を呼び出す簡単な抽象化によってテストを簡潔にできます。

（作為的な）例：

```js
import add from '../add'

test('adds one and two to equal three', () => {
  expect(add(1, 2)).toBe(3)
})

test('adds three and four to equal seven', () => {
  expect(add(3, 4)).toBe(7)
})

test('adds one hundred and two to equal one hundred two', () => {
  expect(add(100, 2)).toBe(102)
})
```

非常にシンプルですが`jest-in-case`で改善できます。

```js
import cases from 'jest-in-case'
import add from '../add'

cases(
  'add',
  ({first, second, result}) => {
    expect(add(first, second)).toBe(result)
  },
  [
    {first: 1, second: 2, result: 3},
    {first: 3, second: 4, result: 7},
    {first: 100, second: 2, result: 102},
  ],
)
```

このような簡単な例でわざわざこのようなことをしないかもしれませんが、配列にただ要素を追加するだけでとても簡単にテストケースを追加できることが魅力です。
このコンセプトの好例（jest-in-case を使っていないもの）は[`rtl-css-js`のテスト](https://github.com/kentcdodds/rtl-css-js/blob/b148865ce6a4c994eba292015b8f44b5dae7edaa/src/__tests__/index.js)です。
このコードベースへのコントリビューターはこの構造で新しいテストケースを追加するのが非常に簡単であることがわかります。

これは純粋ではない関数やモジュールにも適用できますが、もう少し手間がかかります。
（[全く誇れるものではないですがそんなに悪くもないテストがこちらです](https://github.com/kentcdodds/kcd-scripts/blob/7bc29e41e46e73b4b57c0f975648a90a75c24c80/src/scripts/__tests__/lint.js)）。

私は個人的に[jest-in-case](https://github.com/atlassian/jest-in-case)が好みですが、Jest にはビルトインの[`test.each`](https://jestjs.io/docs/api#testeachtable-name-fn-timeout)の機能があり便利かもしれません。

## 結論

確かにテストはより良い名前やコメントによって改善できていましたが、単純な`setup`の抽象化（ちなみにこれは”Test Object Factory”と呼ばれます）ではそれが必要ありません。
つまり私が伝えたいのは：**注意深く抽象化を適用したテストはテストを書いてメンテナンスする手間が少なく済むということです。**

お役に立てれば幸いです！幸運を祈ります！


AHAテスト 💡


これは、[Dominik Dorfmeister 氏](https://tkdodo.eu/)のブログ記事である[React Query as a State Manager](https://tkdodo.eu/blog/react-query-as-a-state-manager)を日本語訳してみたものです。

誤訳などあれば[Issue](https://github.com/makotot/makotot.dev/issues/new)や PR を頂けると幸いです。

---

React Query は React アプリケーションにおけるデータの取得を劇的に単純化するということで多くの方々から愛されています。そのため、私が React Query は実際のところデータ取得のためのライブラリでは*ありません*と伝えると意外に思われるかもしれません。

データを取得してくれるわけではなく、ネットワークに直結するとても小さな機能のまとまりに過ぎません（[OnlineManager](https://react-query-v3.tanstack.com/reference/onlineManager)や*refetchOnReconnect*、[オフライン下で行われたミューテーションの再試行](https://react-query-v3.tanstack.com/guides/mutations#retry)のような）。
実際に何かデータを取得するには[fetch](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API)、[axios](https://axios-http.com/)、[ky](https://github.com/sindresorhus/ky)、[graphql-request](https://github.com/prisma-labs/graphql-request)のようなものを使わないといけないことが、初めて*queryFn*を記述するときに明らかとなります。

では React Query がデータ取得のライブラリじゃないのであれば、一体何なのでしょうか？

## 非同期の状態管理ツール

React Query は非同期の状態管理ツールです。あらゆる形の非同期の状態を管理することができます - Promise が得られさえすれば良いのです。そうです、ほとんどの場合、データの取得で Promise を生み出すので、そこで輝きを放ちます。
ただ、読み込み中やエラーを取り扱うだけのものではありません。ちゃんとした本当の”グローバルの状態管理ツール”です。*QueryKey*はクエリを一意に識別するので、異なる 2 つのところから同じキーでクエリを実行する限りにおいては、同じデータが得られます。
実際のデータを取得する関数に 2 度アクセスする必要がないようにカスタムフックで抽象化するのが最も良いかもしれません。

```tsx async-state-manager
export const useTodos = () => useQuery(['todos'], fetchTodos)

function ComponentOne() {
  const { data } = useTodos()
}

function ComponentTwo() {
  // ✅ ComponentOneと全く同じデータを取得する
  const { data } = useTodos()
}

const queryClient = new QueryClient()

function App() {
  return (
    <QueryClientProvider client={queryClient}>
      <ComponentOne />
      <ComponentTwo />
    </QueryClientProvider>
  )
}
```

このようなコンポーネントをコンポーネントツリーの*どこにでも*置くことができます。
同じ*QueryClientProvider*の配下に置く限り同じデータが得られます。React Query は同時に発生するリクエストの重複を排除するので、上述のような 2 つのコンポーネントで同じデータをリクエストする状況でも 1 つのネットワークリクエストのみとなります。

## データの同期ツール

React Query は非同期の状態（データ取得の観点でいうと：サーバの状態）を管理するので、フロントエンドのアプリケーションがデータを”所有”していないと仮定します。
そしてそれは全体的には正しいです。API から取得したデータを画面に表示するとしたら、そのデータの”スナップショット”を表示するだけ - 取得したときにどのように見えるかのバージョンです。
そこで、私たちが問わなければならない問題は次のものです：

取得した後もそのデータは正確なのでしょうか？

その答えは私たちの問題の領域により全く異なってきます。Twitter の投稿をいいねやコメント付きで取得したら非常に速く最新ではない（古い）ものになっている可能性が高いでしょう。日次で更新される為替レートを取得したらしばらくは再度取得せずとも非常に正確なデータでしょう。

React Query はビューと実際のデータの所有者であるバックエンドを*同期する*ための手段を提供します。そうやって、十分に更新しないより頻繁に更新する方が良いとしています。

### React Query 以前

React Query のようなライブラリが手助けとなる前、データ取得には 2 つのアプローチが非常に一般的でした。

- 1 度取得して、全体に届けて、稀に更新  
  これは私自身が redux で非常によくやることです。どこかで、通常はアプリケーションのマウント時に行う、データ取得を開始するアクションを発行します。データを得た後、そのデータをアプリケーション全体のどこからでも参照できるようにグローバルの状態管理ツールに置きます。
  結局、多くのコンポーネントが Todo リストを参照する必要があります。データを再度取得しますか？いいえ、”ダウンロードして”あり、すでに所有しているものなのでその必要はないでしょう。バックエンドに POST リクエストを送ると”最新の”状態を親切に返してくれるでしょう。
  より正確な情報を得たければいつでもブラウザのウィンドウを再読み込みすれば良いでしょう。。。
- マウントする度に取得してローカルに保持  
  場合によっては、データをグローバルな状態にするのは”過剰”と思えることもあるでしょう。モーダルダイアルの中でだけ必要なデータなのであれば、ダイアログを表示する*ときに限り*取得すれば良いのではないでしょうか。
  ご存知でしょう：空の依存配列（悲鳴が上がったら eslint-disable を投げつけましょう）を持つ*useEffect*と _setLoading(true)_ など。。。もちろんデータが得られるまでダイアログを表示する時に毎回ローディングスピナーが表示されるようになります。
  他にどうすればいいのでしょう、ローカルの状態はなくなってしまっているのに。。。

---

どちらのアプローチもとても最適とはいえません。最初の方法はローカルキャッシュを十分な頻度で更新しませんし、2 つ目の方法は潜在的に取得の頻度が多くなって、2 回目の取得時にはデータがないので UX の面でも疑問があります。

それでは、React Query はこのような問題にどのようにアプローチしているのでしょうか。

### Stale While Revalidate

前に耳にしたことがあるかもしれませんが、これは React Query が使っているキャッシュメカニズムです。何も新しいことありません - [HTTP Cache-Control Extensions for Stale Content についてはこちら](https://datatracker.ietf.org/doc/html/rfc5861)をご覧ください。
手短にいうと、React Query はデータをキャッシュして、そのデータがたとえ最新ではない（古い）としても必要な時に返してくれることを意味します。
その原則は、データがないよりも古いデータがある方がましというもので、なぜならデータが無いということははローディングスピナーを意味して、ユーザーが”遅い”と感じるものだからです。同時に、そのデータを再度確認するためバックグラウンドでのデータ取得を試みます。

### 賢いデータの再取得

キャッシュの無効化は非常に難しいですが、いつ再度新しいデータをバックエンドに要求するのを決めるのでしょうか？もちろん、*useQuery*を呼ぶコンポーネントの再レンダーの度に毎回そうすることはできないでしょう。現代の基準で見てもとても高くつくことになります。

なので、React Query は賢くデータの再取得のトリガーとなる戦略的なポイントを選びます。ポイントというのは、このように言える指標となりそうなものです：”そうだ、今がデータを取ってくるのに良いタイミングだ”。以下のようなものです：

- _refetchOnMount_  
  *useQuery*を呼ぶコンポーネントが新たにマウントされる度に毎回 React Query は再検証します。
- _refetchOnWindowFocus_  
  ブラウザにフォーカスする度にデータの再取得が行われます。これは私が気に入っている再検証タイミングのポイントですが、よく誤解されます。開発時には、とても頻繁にタブを切り替えるので”過剰”だと感じるかもしれません。
  しかし本番環境においては、タブにアプリケーションを開いたままにしておいてメールの確認や Twitter を読むことから戻ってくるようなユーザーが多いようです。
  そのような状況では最新の更新を見せることが理にかなっています。
- _refetchOnReconnect_  
  ネットワーク接続を失った後に戻った時もまた画面に表示するものを再検証するのに良い指標となります。

最終的には、アプリケーションの開発者として良いタイミングのポイントを知っていれば*queryClient.invalidateQueries*によって手動の無効化を呼び出すことができます。これはミューテーションを実行した後にとても重宝します。

### React Query の魔法をかけよう

前にも言ったように、私は[このような初期設定](https://tanstack.com/query/v4/docs/guides/important-defaults?from=reactQueryV3&original=https://react-query-v3.tanstack.com/guides/important-defaults)を好んでいますが、最新の情報を得続けるものであってネットワークリクエストを最少化するためのものではありません。
これは*stealTime*の初期値が 0 であることに起因していて、例えば新しいコンポーネントのインスタンスをマウントする度にバックグラウンドで再度取得することを意味します。
これを頻繁に行うと、特に同じレンダーサイクルではない立て続けのマウントがあると、ネットワークタブに*多く*のデータ取得を目にすることになるかもしれません。何故ならそのような状況で React Query は重複を排除できないからです。

```tsx mounts-in-short-succession
function ComponentOne() {
  const { data } = useTodos()

  if (data) {
    // ⚠️ データを既に持った後に限った条件付きでマウントします
    return <ComponentTwo />
  }
  return <Loading />
}

function ComponentTwo() {
  // ⚠️ 従って2回目のネットワークリクエストを引き起こします
  const { data } = useTodos()
}

const queryClient = new QueryClient()

function App() {
  return (
    <QueryClientProvider client={queryClient}>
      <ComponentOne />
    </QueryClientProvider>
  )
}
```

> どうなっているんでしょう、2 秒前にデータを取得したばかりなのにどうして他のネットワークリクエストが発生するんでしょうか？正気の沙汰ではないです！

— React Query を初めて使ったときの普通の反応

この時点では、このようなデータの取得が全てが過剰なので、props 経由でデータを渡していくか、props ドリルを避けるのに React Context を使うか、_refetchOnMount_ / *refetchOnWindowFocus*フラグを無効にするか、いずれも良いアイディアと思えるかもしれません。

一般的には、props でデータを受け渡すのは何も間違っていません。それはできることが最も明らかなもので上述の例でうまく動くでしょう。しかし、より現実的な状況に例を近づけるよう微調整するとどうでしょうか：

```tsx lazy-second-component
function ComponentOne() {
  const { data } = useTodos()
  const [showMore, toggleShowMore] = React.useReducer(
    (value) => !value,
    false
  )

  // そうです、”ただの”例なのでエラーハンドリングを省いています
  if (!data) {
    return <Loading />
  }

  return (
    <div>
      Todo count: {data.length}
      <button onClick={toggleShowMore}>Show More</button>
      // ✅ ボタンがクリックされたらComponentTwoを表示します
      {showMore ? <ComponentTwo /> : null}
    </div>
  )
}
```

この例では、2 つ目のコンポーネント（これもまた todo のデータに依存している）はユーザーがボタンをクリックした時だけ表示されます。数分後にユーザーがそのボタンをクリックしたと想像してみてください。
その状況では、最新の状態の todo リストを見ることができるようにバックグラウンドでのデータの再取得をするのが良いのではないでしょうか？

もし React Query がやりたいことを基本的に回避するような上述のいずれのアプローチを選択しても実現できません。

ではどうすればケーキを持っていながら食べることもできるのでしょうか？（訳注：両方良いとこどりを意味する表現）

### *staleTime*をカスタマイズする

おそらくどのような方向に話を進めたいのか既にお分かりかもしれません：解決策としては特定のユースケースに適した値を*stealTime*に設定することでしょう：知っておくべきことは：

<div style={{
  padding: "0.5rem",
  border: "1px solid hsl(var(--p)",
}}>
データが新鮮な限りは、常にキャッシュから取得します。新鮮なデータを何度取ってきてもそのデータのネットワークリクエストが表示されることはありません。
</div>

*staleTime*の*正しい*値もまた存在しません。多くの状況においては初期設定でうまく機能します。個人的には、最低 20 秒に設定してその時間枠の重複を削除するのが好みですが、完全にあなた次第です。

#### ボーナス：setQueryDefaults を使う

v3 から[QueryClient.setQueryDefaults](https://tanstack.com/query/v4/docs/reference/QueryClient?from=reactQueryV3&original=https://react-query-v3.tanstack.com/reference/QueryClient#queryclientsetquerydefaults)
でクエリーのキーごとに初期値を設定する素晴らしい方法をサポートするようになりました。[#8: Effective React Query Keys](https://tkdodo.eu/blog/effective-react-query-keys)で紹介したパターンを踏襲することで、
設定したいどのような粒度でも初期値を決められて、なぜなら*setQueryDefaults*にクエリーのキーを渡すと例えば[Query Filters](https://tanstack.com/query/v4/docs/guides/filters?from=reactQueryV3&original=https://react-query-v3.tanstack.com/guides/filters#query-filters)
が持っている標準的な部分一致が適用されるからです：

```tsx setQueryDefaults
const queryClient = new QueryClient({
  defaultOptions: {
    queries: {
      // ✅ グローバルには20秒が初期設定となります
      staleTime: 1000 * 20,
    },
  },
})

// 🚀 todoに関連する全てが1分のstaleTimeとなります
queryClient.setQueryDefaults(todoKeys.all, { staleTime: 1000 * 60 })
```

## 関心の分離についての注意

アプリケーションのあらゆるレイヤーのコンポーネントに*useQuery*のような hooks を追加することはコンポーネントが何をするべきかの責務を混合することへの懸念は一見すると正当なことです。
かつては、”smart-vs-dumb”や”container-vs-presenter”というコンポーネントパターンが普遍的でした。これは”props を受け取る”だけのプレゼンテーションコンポーネントであるために、明らかな分離、疎結合、再利用性、テスト容易性が約束されました。
その一方で、大量の props ドリル、ボイラープレート、型付けが難しいパターン（👋 higher-order-components）、恣意的なコンポーネント分割もまた招きました。

それが hooks の登場によって大きく変わりました。_useContext_、_useQuery_、_useSelector_（redux を使っているのであれば）などをどこでも使えるので、コンポーネントに依存を注入できます。
このようにするとコンポーネントをより結合することになると異議を唱えることができます。より自由にアプリケーションの中で移動できて、それだけで動作するので、より独立性が高まったとも言えます。

redux のメンテナーである[Mark Erikson](https://twitter.com/acemarke)による[Hooks, HOCS, and Tradeoffs (⚡️️) / React Boston 2019](https://www.youtube.com/watch?v=xiKMbmDv-Vw&ab_channel=InsideWayfair)をご覧になることをお勧めします。

要約すると、それは全てトレードオフです。タダで手に入るものはありません。ある状況ではうまく機能するものが別の状況ではうまく機能しないかもしれません。再利用性のある*Button*コンポーネントはデータの取得をするべきでしょうか？おそらくそうではないでしょう。
*Dashboard*を*DashboardView*と*DashboardContainer*とに分けてデータを受け渡すのが理にかなうでしょうか？これもまたそうではないでしょう。そのためトレードオフを知って適材適所でツールを適用することは私たち次第になります。

## まとめ

React Query は、あなたがそうするのであれば、アプリケーションにおけるグローバルな非同期の状態を管理するのに優れています。ユースケースに応じて理にかなった場合に限ってデータ再取得のフラグを無効にして、
サーバのデータを異なる状態管理ツールに同期したくなる衝動を抑えてください。
通常、*staleTime*をカスタマイズすることは優れた UX を実現するためにも、バックグラウンドでの更新頻度を管理するためにも必要なものです。


状態管理ツールとしてのReact Query


これは、[Kent C. Dodds 氏](https://kentcdodds.com/)のブログ記事である[Making your UI tests resilient to change](https://kentcdodds.com/blog/making-your-ui-tests-resilient-to-change)を日本語訳してみたものです。

誤訳などあれば[Issue](https://github.com/makotot/makotot.dev/issues/new)や PR を頂けると幸いです。

---

あなたは開発者で壊れたログイン体験をリリースしたくないので、そうならないことを確認するためにいくつかテストを書くものとします。
そのような[フォームの例](https://github.com/kentcdodds/testing-workshop/blob/1938d6fc2048e55362679905f700f938a3b497c4/client/src/screens/login.js#L50-L82)を見てみましょう：

<img src="/images/content/making-your-ui-tests-resilient-to-change-translation-ja/login.webp" />

```tsx
const form = (
  <form onSubmit={handleSubmit}>
    <div>
      <label htmlFor="username">Username</label>
      <input id="username" className="username-field" />
    </div>
    <div>
      <label htmlFor="password">Password</label>
      <input id="password" type="password" className="password-field" />
    </div>
    <div>
      <button type="submit" className="btn">
        Login
      </button>
    </div>
  </form>
)
```

このフォームをテストするとしら、ユーザー名とパスワードの入力欄を埋めてフォームを送信したいでしょう。それを適切に行うには、フォームをレンダリングしてドキュメントを検索してそれらの node を見つけて操作する必要があります。そのために以下のようなことを試みるかもしれません。

```js
const usernameField = rootNode.querySelector('.username-field')
const passwordField = rootNode.querySelector('.password-field')
const submitButton = rootNode.querySelector('.btn')
```

ここで問題が生じます。
もう 1 つ別のボタンを追加するとしたらどうなるでしょう？ ”Login”ボタンの前に”Sign up”ボタンを追加するとしたら？

```tsx focus=12:14
const form = (
  <form onSubmit={handleSubmit}>
    <div>
      <label htmlFor="username">Username</label>
      <input id="username" className="username-field" />
    </div>
    <div>
      <label htmlFor="password">Password</label>
      <input id="password" type="password" className="password-field" />
    </div>
    <div>
      <button type="submit" className="btn">
        Sign up
      </button>
      <button type="submit" className="btn">
        Login
      </button>
    </div>
  </form>
)
```

おっと、これではテストが壊れてしまいます。ただ、修正することは簡単ですよね？

```js
// change this:
const submitButton = rootNode.querySelector('.btn')
// to this:
const submitButton = rootNode.querySelectorAll('.btn')[1]
```

これでもう大丈夫ですね！それでは、フォームのスタイリングに CSS-in-JS を使い始めることになり username-field と password-field のクラス名がもはや不要になったら、それらを削除するべきでしょうか？それともテストで利用しているのでそのままにするべきでしょうか？うーん。。。。🤔

## それでは変化に強いセレクタをどう書くのでしょう？

[”テストがソフトウェアの使われ方に似てくるほど、より信頼性が高まる”](https://twitter.com/kentcdodds/status/977018512689455106)ことを考えると、どのようなクラス名でもユーザが気にしないことを考えるのは賢明です。

では、チームに手動テスターがいて、そのテスターにページをテストしてもらうための手順を書いているとしましょう。その手順には何が書かれていますか？

1. `username-field`というクラス名の要素を取得します
2. ...

”待ってください”とテスターは言います。”`username-field`というクラス名の要素をどうやって見つけるんですか？”と。

”ああ、devtools を開いて、それから...”

”でもユーザーはそうしないでしょう。`username`というラベルのついた入力欄を見つければいいんじゃないでしょうか？”

”ああ、そうですね、いい考えですね。”

[Testing Library](https://testing-library.com/)が持つクエリの理由はここにあります。このクエリはユーザが見つけるのと同じようにして要素を見つけることの助けとなります。
[role](https://testing-library.com/docs/queries/byrole)、[ラベルのテキスト](https://testing-library.com/docs/queries/bylabeltext)、[プレースホルダのテキスト](https://testing-library.com/docs/queries/byplaceholdertext)、[テキストのコンテンツ](https://testing-library.com/docs/queries/bytext)、[表示されている値](https://testing-library.com/docs/queries/bydisplayvalue)、[alt のテキスト](https://testing-library.com/docs/queries/byalttext)、[タイトル](https://testing-library.com/docs/queries/bytitle)、[test ID](https://testing-library.com/docs/queries/bytestid)などによって要素を探すことができます。

実はこれは[推奨](https://testing-library.com/docs/queries/about/#priority)の順番です。これらのアプローチにトレードオフがあることも確かですが、このクエリを用いて手動テスターに向けて手順を書くとしたら、以下のようになると思います。

1. `username`とラベルつけれらた入力欄に偽の名前を入力します
2. `password`とラベルつけられた入力欄に偽のパスワードを入力します
3. `sign in`というテキストのボタンをクリックします

```js
const usernameField = rootNode.getByRole('textbox', {name: /username/i})
const passwordField = rootNode.getByLabelText('password')
const submitButton = rootNode.getByRole('button', {name: /sign in/i})
```

そうすると、可能な限りソフトウェアが利用されるのと同じようにテストすることにつながります。テストからより多くの価値を得られるでしょう。

## `data-testid`クエリはどうしたんでしょうか？

他のどのクエリでも要素を選択できないことが時としてあります。そのような場合に`data-testid`を利用することが推奨されます（ただ、最初に適切な`role`属性の指定漏れなどないかを確かめる必要があります）。

この状況に直面した多くの人は`getByClassName`クエリを含まない理由を不思議に思います。クラス名をセレクタに利用することを私が嫌う理由は、通常、クラス名をスタイリングのためのものと考えるからです。
そのため、それ以外の目的で多くのクラス名をを追加し始めると、そのクラス名が何のためにあるのかも、いつそのクラス名を削除できるのかも<strong><em>一層</em></strong>分からなくなります。

また、すでにスタイリングのために使っているクラス名をただ再利用しようとしても上述のボタンのような問題に直面します。
そして、_”リファクタリングや機能追加の度にテストを修正しなければならないのであれば、テストが脆いことの表れとなります”_。問題の核心はテストとソースコードの関係があまりにも暗黙的であることです。**両者の関係をより明示的にする**ことでこの問題を克服できます。

もし選択しようとしている要素にメタデータを追加できるのであれば、問題を解決できます。聞いてください！実はこのための API が存在します！それは`data-*`属性です！例えば：

```tsx
function UsernameDisplay({user}) {
  return <strong data-testid="username">{user.username}</strong>
}
```

そしてテストはこうなります：

```js
const usernameEl = getByTestId('username')
```

これは[E2E テスト](https://github.com/kentcdodds/jest-cypress-react-babel-webpack/blob/1c842dff85cd83953e86a6f1a48653b15fb3a4d5/cypress/e2e/register.js#L20)にも最適です。なので、そちらでも使用することをお勧めします。
ただし、このような属性を本番環境に公開することに懸念があると伝えてきた人もいます。もしあなたもそうなら、本当にそれが実際のところ問題かどうか考えてみてください（なぜなら正直言ってあなたが考えているほど大きな問題ではないでしょうから）。
それでも本当にそうしたいのであれば、[`babel-plugin-react-remove-properties`](https://www.npmjs.com/package/babel-plugin-react-remove-properties)でそのような属性を取り除いてコンパイルすることができます。

## 結論

ソフトウェアが使われるのと同じようにアプリケーションをテストすると、変更に強いだけではなく、より多くの価値を提供してくれることに気づくでしょう。
これに関してより学びたければ、私のブログ記事である[Testing Implementation Details](https://kentcdodds.com/blog/testing-implementation-details)をお勧めします。

この記事がお役に立てば幸いです。幸運を祈ります！


変更に強いUIテストの実現


これは、[Kent C. Dodds 氏](https://kentcdodds.com/)のブログ記事である[UI Testing Myths](https://kentcdodds.com/blog/ui-testing-myths)を日本語訳してみたものです。

誤訳などあれば[Issue](https://github.com/makotot/makotot.dev/issues/new)や PR を頂けると幸いです。

---

### 神話 1: ”コードに変更を加えるといつもテストが壊れる”

実際のところこれは本当です。。誤ったテストが書かれていれば。もし実装詳細をテストしていれば、当然実装が変更された時にテストが壊れます！ですがユーザーは実装詳細に関心がありません。実際、ユーザーは React でも Angular でも jQuery でも何が使われているかを気にしません。なので、ほとんどの場合、テストについてもそのことを気にする必要がありません。💯

残念なことに、多くのツールは実装詳細のテストを推奨しています。それに従うと、テストを書き直すことが多くなる傾向にあります。”なぜこのようなものまでテストしているのか？”と自問するかもしれませんが、それも仕方のないことです。それが[TestingJavaScript.com](https://testingjavascript.com/)において私が*正しい*テストのやり方を伝えている理由です。

### 神話 2: ”redux に'繋いだ'コンポーネントをテストできない”

Redux を使っているコンポーネントのテストの従来の常識は、コンポーネントを Redux から分離してテストして、Redux の action creator や reducer を分けてテストするというものでした。

ですが、このようにすると、テストはコンポーネントが Redux*と*適切に連携できているかどうかについての信頼を全く与えてくれません。

代わりに、本当の Redux store と繋いだコンポーネントを実際にテストすることができます。そうすると、コンポーネントが適切にレンダリングされること*と*Redux の action creator や reducer が全て一緒に連動して機能していることに信頼を与えてくれます。本番と同じように。 ✅

[TestingJavaScript.com](https://testingjavascript.com/)において、私はこのようなテストの方法について紹介しています。React Router🔀 や他のプロバイダー（emotion 👩‍🎤 の Theme Provider など）にも同じ考え方を適用できて、このコースではどのようにしてそれらを適用するのかも紹介しています！

### 神話 3: ”E2E テストは遅くて脆い”

これも誤ったテストが書かれている場合に本当のことになります。私が E2E テストにおいてよく目にする間違いは、テスト毎に同じことをしているというものです—例えば、全てのテストがテストで必要なことの前に、登録とログインの全フローを行うということです。こういうことをすると、多くの重複を目にすることになり、”page objects”（悪いプラクティスです）のようなものを作り始めるわけです。 😐

[TestingJavaScript.com](https://testingjavascript.com/)において、私は登録とログインのフローが機能していることに自信が持てる方法を紹介していて、残りのテストではそれらをスキップすることで格段に速くして、障害点を減らすようにしています。[Cypress Testing Library](https://github.com/testing-library/cypress-testing-library)のようなツールを利用してこのような形でテストをすると、page objects のようなプラクティスは全く必要のないものとなり、テストのメンテナンスが容易になり、信頼できて、より高速に実行できるようになります。開発のワークフローツールとして Chrome を Cypress へと置き換えることさえありえるかもしれません（その方法もまたコースで紹介しています！）😱
