Merge pull request #262 from reactjs/tr/testing-env

Translate testing-environment

Author: smikitky

content/docs/nav.yml

@@ -134,7 +134,7 @@
     - id: testing-recipes
       title: テストのレシピ集
     - id: testing-environments
-      title: Testing Environments
+      title: テスト環境
 - title: Concurrent Mode (Experimental)
   isOrdered: true
   items:

content/docs/testing-environments.md

@@ -1,58 +1,58 @@
 ---
 id: testing-environments
-title: Testing Environments
+title: テスト環境
 permalink: docs/testing-environments.html
 prev: testing-recipes.html
 ---
 
 <!-- This document is intended for folks who are comfortable with JavaScript, and have probably written tests with it. It acts as a reference for the differences in testing environments for React components, and how those differences affect the tests that they write. This document also assumes a slant towards web-based react-dom components, but has notes for other renderers. -->
 
-This document goes through the factors that can affect your environment and recommendations for some scenarios.
+このドキュメントではあなたの環境に影響する要素や、いくつかのシナリオにおける推奨事項について概説します。
 
-### Test runners {#test-runners}
+### テストランナー {#test-runners}
 
-Test runners like [Jest](https://jestjs.io/), [mocha](https://mochajs.org/), [ava](https://github.com/avajs/ava) let you write test suites as regular JavaScript, and run them as part of your development process. Additionally, test suites are run as part of continuous integration.
+[Jest](https://jestjs.io/)、[mocha](https://mochajs.org/)、[ava](https://github.com/avajs/ava) のようなテストランナーを使えば、標準的な JavaScript を使ってテストスイートを書き、開発プロセスの一環として実行できるようにできます。加えて、テストスイートは継続的インテグレーションの一部としても実行されます。
 
-- Jest is widely compatible with React projects, supporting features like mocked [modules](#mocking-modules) and [timers](#mocking-timers), and [`jsdom`](#mocking-a-rendering-surface) support. **If you use Create React App, [Jest is already included out of the box](https://facebook.github.io/create-react-app/docs/running-tests) with useful defaults.**
-- Libraries like [mocha](https://mochajs.org/#running-mocha-in-the-browser) work well in real browser environments, and could help for tests that explicitly need it.
-- End-to-end tests are used for testing longer flows across multiple pages, and require a [different setup](#end-to-end-tests-aka-e2e-tests).
+- Jest は React プロジェクトとの広範な互換性を有しており、[モジュール](#mocking-modules)や[タイマー](#mocking-timers)のモック、[`jsdom`](#mocking-a-rendering-surface) のサポートを有しています。**Create React App を使っている場合、Jest は有用なデフォルト値とともに[追加設定なしでインストールされます](https://facebook.github.io/create-react-app/docs/running-tests)**。
+- [mocha](https://mochajs.org/#running-mocha-in-the-browser) のようなライブラリは実際のブラウザ環境でうまく動作するため、それが必要なテストでは有用でしょう。
+- End-to-end テストは複数のページにまたがる長いフローのテストに使用され、[異なったセットアップ](#end-to-end-tests-aka-e2e-tests)が必要です。
 
-### Mocking a rendering surface {#mocking-a-rendering-surface}
+### 描画画面のモック {#mocking-a-rendering-surface}
 
-Tests often run in an environment without access to a real rendering surface like a browser. For these environments, we recommend simulating a browser with [`jsdom`](https://github.com/jsdom/jsdom), a lightweight browser implementation that runs inside Node.js.
+しばしばテストは、ブラウザのような実際の描画用の画面にアクセスできない環境で実行されます。このような環境では、Node.js 内で実行される軽量のブラウザ実装である [`jsdom`](https://github.com/jsdom/jsdom) を使ってブラウザ環境をシミュレートすることをお勧めします。
 
-In most cases, jsdom behaves like a regular browser would, but doesn't have features like [layout and navigation](https://github.com/jsdom/jsdom#unimplemented-parts-of-the-web-platform). This is still useful for most web-based component tests, since it runs quicker than having to start up a browser for each test. It also runs in the same process as your tests, so you can write code to examine and assert on the rendered DOM.
+多くの場合、jsdom は普通のブラウザの挙動と同様に動作しますが、[レイアウトやナビゲーション](https://github.com/jsdom/jsdom#unimplemented-parts-of-the-web-platform)のような機能は有していません。それでも、個々のテストでブラウザを立ち上げるよりも高速に動作するので、ほとんどのウェブベースのコンポーネントのテストでは有用です。また、jsdom はあなたのテストと同一のプロセスで動作するため、描画された DOM に対して内容を調べたりアサーションを行うコードを書くことができます。
 
-Just like in a real browser, jsdom lets us model user interactions; tests can dispatch events on DOM nodes, and then observe and assert on the side effects of these actions [<small>(example)</small>](/docs/testing-recipes.html#events).
+本物のブラウザと全く同様に、jsdom ではユーザ操作をモデルすることができます。テストは DOM ノードに対してイベントをディスパッチして、そのアクションに対する副作用を観察したり検証したりすることができます[<small>（例）</small>](/docs/testing-recipes.html#events)。
 
-A large portion of UI tests can be written with the above setup: using Jest as a test runner, rendered to jsdom, with user interactions specified as sequences of browser events, powered by the `act()` helper [<small>(example)</small>](/docs/testing-recipes.html). For example, a lot of React's own tests are written with this combination.
+UI テストの大部分は上記のようなセットアップを行って書くことができます。すなわちテストランナーとして Jest を使い、jsdom にレンダーし、ブラウザイベントの羅列としてユーザ操作を定義し、`act()` ヘルパを活用します[<small>（例）</small>](/docs/testing-recipes.html)。例えば、React 自体のテストの多くもこの組み合わせで書かれています。
 
-If you're writing a library that tests mostly browser-specific behavior, and requires native browser behavior like layout or real inputs, you could use a framework like [mocha.](https://mochajs.org/)
+主にブラウザ特有の動作をテストする必要があるライブラリを書いており、レイアウトや本物のユーザ入力などネイティブなブラウザの挙動が必要な場合は、[mocha](https://mochajs.org/) のようなフレームワークを利用できます。
 
-In an environment where you _can't_ simulate a DOM (e.g. testing React Native components on Node.js), you could use [event simulation helpers](https://reactjs.org/docs/test-utils.html#simulate) to simulate interactions with elements. Alternately, you could use the `fireEvent` helper from [`@testing-library/react-native`](https://testing-library.com/docs/native-testing-library).
+DOM をシミュレート*できない*環境（例えば Node.js で React Native のコンポーネントをテストする場合など）では、[イベントシミュレーションヘルパ](https://reactjs.org/docs/test-utils.html#simulate)を使って要素とのインタラクションをシミュレーションできます。あるいは、[`@testing-library/react-native`](https://testing-library.com/docs/native-testing-library) の `fireEvent` ヘルパを利用することもできます。
 
-Frameworks like [Cypress](https://www.cypress.io/), [puppeteer](https://github.com/GoogleChrome/puppeteer) and [webdriver](https://www.seleniumhq.org/projects/webdriver/) are useful for running [end-to-end tests](#end-to-end-tests-aka-e2e-tests).
+[Cypress](https://www.cypress.io/)、[puppeteer](https://github.com/GoogleChrome/puppeteer)、[webdriver](https://www.seleniumhq.org/projects/webdriver/) のようなフレームワークは [end-to-end テスト](#end-to-end-tests-aka-e2e-tests)を実行するのに有用です。
 
-### Mocking functions {#mocking-functions}
+### 関数のモック {#mocking-functions}
 
-When writing tests, we'd like to mock out the parts of our code that don't have equivalents inside our testing environment (e.g. checking `navigator.onLine` status inside Node.js). Tests could also spy on some functions, and observe how other parts of the test interact with them. It is then useful to be able to selectively mock these functions with test-friendly versions.
+テストを書く際は、テスト環境に同等物がないコード（例えば `navigator.onLine` の状態を Node.js 内で確認する、など）のモック化をしたくなります。テストではいくつかの関数を監視し、テストの他の部位がその関数とどう作用するのかを観察することもできます。そのような場合に、これらの関数をテストしやすいバージョンで選択的にモック化できれば有用です。
 
-This is especially useful for data fetching. It is usually preferable to use "fake" data for tests to avoid the slowness and flakiness due to fetching from real API endpoints [<small>(example)</small>](/docs/testing-recipes.html#data-fetching). This helps make the tests predictable. Libraries like [Jest](https://jestjs.io/) and [sinon](https://sinonjs.org/), among others, support mocked functions. For end-to-end tests, mocking network can be more difficult, but you might also want to test the real API endpoints in them anyway.
+これはデータを取得する場面では特に有用です。本物の API エンドポイントからデータを取得することによって遅くなったり不安定になったりするのを避けるため、通常はフェイクデータを利用することが望まれます[<small>（例）</small>](/docs/testing-recipes.html#data-fetching)。これによりテストが予想可能になります。[Jest](https://jestjs.io/) や [sinon](https://sinonjs.org/) などのライブラリはモック関数をサポートしています。End-to-end テストの場合、ネットワークのモックはより困難ですが、いずれにせよそのようなテストでは本物の API エンドポイントを使ってテストをしたいでしょう。
 
-### Mocking modules {#mocking-modules}
+### モジュールのモック {#mocking-modules}
 
-Some components have dependencies for modules that may not work well in test environments, or aren't essential to our tests. It can be useful to selectively mock these modules out with suitable replacements [<small>(example)</small>](/docs/testing-recipes.html#mocking-modules).
+コンポーネントによってはテスト環境でうまく動作しないか、テストにとって本質的ではないモジュールに依存していることがあります。このようなモジュールを選択的にモック化して適切な代替物で置き換えることは有用です[<small>（例）</small>](/docs/testing-recipes.html#mocking-modules)。
 
-On Node.js, runners like Jest [support mocking modules](https://jestjs.io/docs/en/manual-mocks). You could also use libraries like [`mock-require`](https://www.npmjs.com/package/mock-require).
+Node.js では、Jest のようなテストランナーは[モジュールのモックをサポートしています](https://jestjs.io/docs/en/manual-mocks)。[`mock-require`](https://www.npmjs.com/package/mock-require) のようなライブラリを使用することもできます。
 
-### Mocking timers {#mocking-timers}
+### タイマーのモック {#mocking-timers}
 
-Components might be using time-based functions like `setTimeout`, `setInterval`, or `Date.now`. In testing environments, it can be helpful to mock these functions out with replacements that let you manually "advance" time. This is great for making sure your tests run fast! Tests that are dependent on timers would still resolve in order, but quicker [<small>(example)</small>](/docs/testing-recipes.html#timers). Most frameworks, including [Jest](https://jestjs.io/docs/en/timer-mocks), [sinon](https://sinonjs.org/releases/v7.3.2/fake-timers/) and [lolex](https://github.com/sinonjs/lolex), let you mock timers in your tests.
+コンポーネントは `setTimeout`、`setInterval` や `Date.now` のような時間に依存する関数を使っているかもしれません。テスト環境では、これらの関数をモック版で置き換えて、手動で時間を「進められる」ようにすることが有用です。これはテストを高速に実行させるためにも役立ちます！ タイマーに依存しているテストは順番通りに処理されますが、より高速になるのです[<small>（例）</small>](/docs/testing-recipes.html#timers)。[Jest](https://jestjs.io/docs/en/timer-mocks)、[sinon](https://sinonjs.org/releases/v7.3.2/fake-timers/) や [lolex](https://github.com/sinonjs/lolex) を含むほとんどのフレームワークにおいて、テストでモックタイマーを利用できます。
 
-Sometimes, you may not want to mock timers. For example, maybe you're testing an animation, or interacting with an endpoint that's sensitive to timing (like an API rate limiter). Libraries with timer mocks let you enable and disable them on a per test/suite basis, so you can explicitly choose how these tests would run.
+時には、タイマーのモックをやりたくない場合があります。例えばアニメーションや、タイミングに依存するエンドポイント（API レートリミッタなど）をテストしているのかもしれません。タイマーのモックが利用できるライブラリでは、テストあるいはスイートごとにモックを有効化・無効化できるようになっているため、どのようにテストを実行するかを明示的に選択できます。
 
-### End-to-end tests {#end-to-end-tests-aka-e2e-tests}
+### End-to-end テスト {#end-to-end-tests-aka-e2e-tests}
 
-End-to-end tests are useful for testing longer workflows, especially when they're critical to your business (such as payments or signups). For these tests, you'd probably want to test both how a real browser renders the whole app, fetches data from the real API endpoints, uses sessions and cookies, navigates between different links. You might also likely want to make assertions not just on the DOM state, but on the backing data as well (e.g. to verify whether the updates have been persisted to the database).
+End-to-end テストは長いワークフロー、特にあなたの業務にとってとても重要なワークフロー（例えば支払いやサインアップ）をテストするのに有用です。これらのテストをする際は、本物のブラウザがアプリケーション全体をいかに描画し、本物の API エンドポイントからいかにデータを取得し、セッションやクッキーをいかに使い、さまざまなリンク間でいかにナビゲーションするかを試験したいでしょう。また、おそらく DOM の状態だけではなく、バックエンドのデータに対する検証（例えばデータベースに更新が正しく永続化されているかの確認）も行いたいかもしれません。
 
-In this scenario, you would use a framework like [Cypress](https://www.cypress.io/) or a library like [puppeteer](https://github.com/GoogleChrome/puppeteer) so you can navigate between multiple routes and assert on side effects not just in the browser, but potentially on the backend as well.
+このようなシナリオの場合は、[Cypress](https://www.cypress.io/) のようなフレームワークや [puppeteer](https://github.com/GoogleChrome/puppeteer) のようなライブラリを使うことで、複数のルート間をナビゲートし、ブラウザのみならず、必要に応じてバックエンド側の副作用についても検証を行うことができるでしょう。