You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/docs/testing-recipes.md
+51-51
Original file line number
Diff line number
Diff line change
@@ -1,37 +1,37 @@
1
1
---
2
2
id: testing-recipes
3
-
title: Testing Recipes
3
+
title: テストのレシピ集
4
4
permalink: docs/testing-recipes.html
5
5
prev: testing.html
6
6
next: testing-environments.html
7
7
---
8
8
9
-
Common testing patterns for React components.
9
+
React コンポーネントのための一般的なテストのパターン集です。
10
10
11
-
> Note:
11
+
> 補足：
12
12
>
13
-
> This page assumes you're using [Jest](https://jestjs.io/)as a test runner. If you use a different test runner, you may need to adjust the API, but the overall shape of the solution will likely be the same. Read more details on setting up a testing environment on the [Testing Environments](/docs/testing-environments.html)page.
13
+
> このページではテストランナーとして [Jest](https://jestjs.io/)を使用することを前提としています。もし別のテストランナーを使う場合は API を修正する必要があるかもしれませんが、やり方の全体的な見た目についてはおそらく同じようなものになるはずです。テスト環境のセットアップについては [テスト環境](/docs/testing-environments.html)のページをご覧ください。
14
14
15
-
On this page, we will primarily use function components. However, these testing strategies don't depend on implementation details, and work just as well for class components too.
For each test, we usually want to render our React tree to a DOM element that's attached to `document`. This is important so that it can receive DOM events. When the test ends, we want to "clean up" and unmount the tree from the `document`.
32
+
それぞれのテストにおいて、通常われわれは React ツリーを `document` に結びついた DOM 要素として描画することになります。これは DOM イベントを受け取れるようにするために重要です。テストが終了した際に「クリーンアップ」を行い、`document` からツリーをアンマウントします。
33
33
34
-
A common way to do it is to use a pair of `beforeEach`and`afterEach`blocks so that they'll always run and isolate the effects of a test to itself:
You may use a different pattern, but keep in mind that we want to execute the cleanup _even if a test fails_. Otherwise, tests can become "leaky", and one test can change the behavior of another test. That makes them difficult to debug.
When writing UI tests, tasks like rendering, user events, or data fetching can be considered as "units" of interaction with a user interface. React provides a helper called `act()`that makes sure all updates related to these "units" have been processed and applied to the DOM before you make any assertions:
This helps make your tests run closer to what real users would experience when using your application. The rest of these examples use `act()`to make these guarantees.
You might find using `act()`directly a bit too verbose. To avoid some of the boilerplate, you could use a library like [React Testing Library](https://testing-library.com/react), whose helpers are wrapped with `act()`.
Commonly, you might want to test whether a component renders correctly for given props. Consider a simple component that renders a message based on a prop:
@@ -94,7 +94,7 @@ export default function Hello(props) {
94
94
}
95
95
```
96
96
97
-
We can write a test for this component:
97
+
このコンポーネントのテストは以下のように書くことができます：
98
98
99
99
```jsx{24-27}
100
100
// hello.test.js
@@ -139,9 +139,9 @@ it("renders with or without a name", () => {
139
139
140
140
---
141
141
142
-
### Data Fetching {#data-fetching}
142
+
### データの取得 {#data-fetching}
143
143
144
-
Instead of calling real APIs in all your tests, you can mock requests with dummy data. Mocking data fetching with "fake" data prevents flaky tests due to an unavailable backend, and makes them run faster. Note: you may still want to run a subset of tests using an ["end-to-end"](/docs/testing-environments.html#end-to-end-tests-aka-e2e-tests)framework that tells whether the whole app is working together.
144
+
あなたのテスト内で本物の API を呼ぶかわりに、リクエストをモック化してダミーのデータを返すようにできます。データ取得をモック化して「フェイク」のデータを使うことで、バックエンドが利用できないせいでテストが不安定にならずに済み、テストの動作が高速になります。とはいえ、テストの一部については、アプリケーション全体が協調して動作しているかを確認できる ["end-to-end"](/docs/testing-environments.html#end-to-end-tests-aka-e2e-tests)のフレームワークを利用して実行したいかもしれません。
145
145
146
146
```jsx
147
147
// user.js
@@ -175,7 +175,7 @@ export default function User(props) {
Some modules might not work well inside a testing environment, or may not be as essential to the test itself. Mocking out these modules with dummy replacements can make it easier to write tests for your own code.
We recommend dispatching real DOM events on DOM elements, and then asserting on the result. Consider a `Toggle`component:
342
+
DOM 要素に対して本物の DOM イベントをディスパッチし、その結果に対してアサーションを行うことをお勧めします。以下の `Toggle`コンポーネントを考えてみましょう：
343
343
344
344
```jsx
345
345
// toggle.js
@@ -362,7 +362,7 @@ export default function Toggle(props) {
362
362
}
363
363
```
364
364
365
-
We could write tests for it:
365
+
これに対するテストは以下のように書けます：
366
366
367
367
```jsx{13-14,35,43}
368
368
// toggle.test.js
@@ -416,17 +416,17 @@ it("changes value when clicked", () => {
416
416
});
417
417
```
418
418
419
-
Different DOM events and their properties are described in [MDN](https://developer.mozilla.org/en-US/docs/Web/API/MouseEvent). Note that you need to pass `{ bubbles: true }`in each event you create for it to reach the React listener because React automatically delegates events to the document.
Your code might use timer-based functions like `setTimeout`to schedule more work in the future. In this example, a multiple choice panel waits for a selection and advances, timing out if a selection isn't made in 5 seconds:
@@ -455,7 +455,7 @@ export default function Card(props) {
455
455
}
456
456
```
457
457
458
-
We can write tests for this component by leveraging [Jest's timer mocks](https://jestjs.io/docs/en/timer-mocks), and testing the different states it can be in.
You can use fake timers only in some tests. Above, we enabled them by calling `jest.useFakeTimers()`. The main advantage they provide is that your test doesn't actually have to wait five seconds to execute, and you also didn't need to make the component code more convoluted just for testing.
Frameworks like Jest also let you save "snapshots" of data with [`toMatchSnapshot` / `toMatchInlineSnapshot`](https://jestjs.io/docs/en/snapshot-testing). With these, we can "save" the rendered component output and ensure that a change to it has to be explicitly committed as a change to the snapshot.
546
+
Jest のようなフレームワークでは、[`toMatchSnapshot` / `toMatchInlineSnapshot`](https://jestjs.io/docs/en/snapshot-testing) を使ってデータの「スナップショット」を保存することができます。これを使うことで、レンダーされたコンポーネントの出力を「セーブ」しておき、変更がスナップショットへの変更として明示的にコミットされるよう保証することができます。
547
547
548
-
In this example, we render a component and format the rendered HTML with the [`pretty`](https://www.npmjs.com/package/pretty)package, before saving it as an inline snapshot:
548
+
以下の例では、コンポーネントをレンダーし、作成された HTML を [`pretty`](https://www.npmjs.com/package/pretty)パッケージで整形し、インラインスナップショットとして保存します：
It's typically better to make more specific assertions than to use snapshots. These kinds of tests include implementation details so they break easily, and teams can get desensitized to snapshot breakages. Selectively [mocking some child components](#mocking-modules) can help reduce the size of snapshots and keep them readable for the code review.
In rare cases, you may be running a test on a component that uses multiple renderers. For example, you may be running snapshot tests on a component with `react-test-renderer`, that internally uses `ReactDOM.render`inside a child component to render some content. In this scenario, you can wrap updates with `act()`s corresponding to their renderers.
If some common scenario is not covered, please let us know on the [issue tracker](https://github.com/reactjs/reactjs.org/issues) for the documentation website.
0 commit comments