Merge pull request #16196 from yiijan/guide-ja-test-rev

guide-ja/test-* revised [ci skip]

docs/guide-ja/rest-rate-limiting.md

@@ -14,7 +14,8 @@
 * `saveAllowance()`: 許可されているリクエストの残り数と現在の UNIX タイムスタンプの両方を保存します。
 
 ユーザ・テーブルに二つのカラムを追加して、許容されているリクエスト数とタイムスタンプの情報を記録するのが良いでしょう。
-それらを定義すれば、`loadAllowance()` と `saveAllowance()` は、認証された現在のユーザに対応する二つのカラムの値を読み書きするものとして実装することが出来ます。
+それらを定義すれば、`loadAllowance()` と `saveAllowance()` は、
+認証された現在のユーザに対応する二つのカラムの値を読み書きするものとして実装することが出来ます。
 パフォーマンスを向上させるために、これらの情報をキャッシュや NoSQL ストレージに保存することを検討しても構いません。
 
 `User` モデルにおける実装は次のようなものになります。
@@ -38,10 +39,12 @@ public function saveAllowance($request, $action, $allowance, $timestamp)
 }
 ```
 
-アイデンティティのクラスに必要なインタフェイスを実装すると、Yii は [[yii\rest\Controller]] のアクション・フィルタとして構成された [[yii\filters\RateLimiter]] を使って、自動的にレート制限のチェックを行うようになります。
+アイデンティティのクラスに必要なインタフェイスを実装すると、Yii は [[yii\rest\Controller]] のアクション・フィルタとして構成された
+[[yii\filters\RateLimiter]] を使って、自動的にレート制限のチェックを行うようになります。
 レート制限を超えると、レート・リミッタが [[yii\web\TooManyRequestsHttpException]] を投げます。
 
-レート・リミッタは、REST コントローラ・クラスの中で、次のようにして構成することが出来ます。
+レート・リミッタは、REST コントローラ・クラスの中で、
+次のようにして構成することが出来ます。
 
 ```php
 public function behaviors()
@@ -52,10 +55,12 @@ public function behaviors()
 }
 ```
 
-レート制限が有効にされると、デフォルトでは、送信される全てのレスポンスに、現在のレート制限の情報を含む次の HTTP ヘッダが付加されます。
+レート制限が有効にされると、デフォルトでは、送信される全てのレスポンスに、
+現在のレート制限の情報を含む次の HTTP ヘッダが付加されます。
 
 * `X-Rate-Limit-Limit` - 一定期間内に許可されるリクエストの最大数
 * `X-Rate-Limit-Remaining` - 現在の期間において残っている許可されているリクエスト数
 * `X-Rate-Limit-Reset` - 許可されているリクエストの最大数にリセットされるまで待たなければならない秒数
 
-これらのヘッダは、上記のコード例で示されているように、[[yii\filters\RateLimiter::enableRateLimitHeaders]] を `false` に設定することで無効にすることが出来ます。
+これらのヘッダは、上記のコード例で示されているように、[[yii\filters\RateLimiter::enableRateLimitHeaders]] を
+`false` に設定することで無効にすることが出来ます。

docs/guide-ja/test-acceptance.md

@@ -1,8 +1,7 @@
 受入テスト
 ==========
 
-受入テストはユーザの視点からシナリオを検証するものです。
-テストされるアプリケーションは PhpBrowser または実際のブラウザによってアクセスされます。
+受入テストはユーザの視点からシナリオを検証するものです。テストされるアプリケーションは PhpBrowser または実際のブラウザによってアクセスされます。
 どちらの場合でも、ブラウザは HTTP によって通信しますので、アプリケーションはウェブ・サーバによってホストされる必要があります。
 
 受入テストは Codeception フレームワークの助けを借りて実装されています。Codeception フレームワークには優れたドキュメントがありますので、参照して下さい。

docs/guide-ja/test-environment-setup.md

@@ -1,16 +1,20 @@
 テスト環境の構築
 ================
 
-Yii 2 は [`Codeception`](https://github.com/Codeception/Codeception) テスト・フレームワークとの統合を公式にサポートしており、次のタイプのテストを作成することを可能にしています。
+Yii 2 は [`Codeception`](https://github.com/Codeception/Codeception) テスト・フレームワークとの統合を公式にサポートしており、
+次のタイプのテストを作成することを可能にしています。
 
 - [単体テスト](test-unit.md) - 一かたまりのコードが期待通りに動くことを検証する。
 - [機能テスト](test-functional.md) - ブラウザのエミュレーションによって、ユーザの視点からシナリオを検証する。
 - [受入テスト](test-acceptance.md) - ブラウザの中で、ユーザの視点からシナリオを検証する。
 
-これら三つのタイプのテスト全てについて、Yii は、[`yii2-basic`](https://github.com/yiisoft/yii2-app-basic) と [`yii2-advanced`](https://github.com/yiisoft/yii2-app-advanced) の両方のプロジェクト・テンプレートで、そのまま使えるテストセットを提供しています。
+これら三つのタイプのテスト全てについて、Yii は、[`yii2-basic`](https://github.com/yiisoft/yii2-app-basic) と
+[`yii2-advanced`](https://github.com/yiisoft/yii2-app-advanced) の両方のプロジェクト・テンプレートで、
+そのまま使えるテストセットを提供しています。
 
 ベーシック・テンプレート、アドバンスト・テンプレートの両方とも、Codeception がプリ・インストールされて付いて来ます。
-これらのテンプレートの一つを使っていない場合は、下記のコンソールコマンドを発行することで Codeception をインストールすることが出来ます。
+これらのテンプレートの一つを使っていない場合は、下記のコンソールコマンドを発行することで
+Codeception をインストールすることが出来ます。
 
 ```
 composer require codeception/codeception

docs/guide-ja/test-fixtures.md

@@ -101,7 +101,8 @@ class UserProfileFixture extends ActiveFixture
 また、同じ理由によって、`UserFixture` は常に `UserProfileFixture` がアンロードされた後でアンロードされます。
 
 上記では、DB テーブルに関してフィクスチャを定義する方法を示しました。
-DB と関係しないフィクスチャ (例えば、何らかのファイルやディレクトリに関するフィクスチャ) を定義するためには、より汎用的な基底クラス [[yii\test\Fixture]] から拡張して、[[yii\test\Fixture::load()|load()]] と [[yii\test\Fixture::unload()|unload()]] のメソッドをオーバーライドすることが出来ます。
+DB と関係しないフィクスチャ (例えば、何らかのファイルやディレクトリに関するフィクスチャ) を定義するためには、より汎用的な基底クラス [[yii\test\Fixture]] から拡張して、
+[[yii\test\Fixture::load()|load()]] と [[yii\test\Fixture::unload()|unload()]] のメソッドをオーバーライドすることが出来ます。
 
 
 ## フィクスチャを使用する
@@ -109,13 +110,13 @@ DB と関係しないフィクスチャ (例えば、何らかのファイルや
 [Codeception](http://codeception.com/) を使ってコードをテストしている場合は、フィクスチャのローディングとアクセスについては、
 内蔵されているサポートを使用することが出来ます。
 
-その他のテスト・フレームワークを使っている場合は、テスト・ケースで [[yii\test\FixtureTrait]] を使って同じ目的を達することが出来ます。
+その他のテスト・フレームワークを使っている場合は、テスト・ケースで [[yii\test\FixtureTrait]]
+を使って同じ目的を達することが出来ます。
 
 次に、Codeception を使って `UserProfile` 単体テストクラスを書く方法を説明します。
 
 `\Codeception\Test\Unit` を拡張するあなたの単体テスト・クラスにおいて、 `_fixtures()` メソッドの中で使いたいフィクスチャを宣言するか、
-または、アクターの `haveFixtures()` メソッドを直接に使用します。
-例えば、
+または、アクターの `haveFixtures()` メソッドを直接に使用します。例えば、
 
 ```php
 namespace app\tests\unit\models;
@@ -149,17 +150,17 @@ class UserProfileTest extends \Codeception\Test\Unit
 クラス名あるいはフィクスチャを指す構成情報配列を使うことが出来ます。
 構成情報配列を使うと、フィクスチャがロードされるときのフィクスチャのプロパティをカスタマイズすることが出来ます。
 
-また、フィクスチャにエイリアスを割り当てることも出来ます。
-上記の例では、`UserProfileFixture` に `profiles` というエイリアスが与えられています。
-そうすると、テスト・メソッドの中でエイリアスを使ってフィクスチャ・オブジェクトにアクセスすることが出来るようになります。
-例えば、
+また、フィクスチャにエイリアスを割り当てることも出来ます。上記の例では、`UserProfileFixture` に `profiles` というエイリアスが与えられています。
+そうすると、テスト・メソッドの中でエイリアスを使ってフィクスチャ・オブジェクトにアクセスすることが出来るようになります。例えば、
 
 ```php
 $profile = $I->grabFixture('profiles', 'user1');
 ```
+
 は `UserProfileFixture` オブジェクトを返します。
 
-さらには、`UserProfileFixture` は `ActiveFixture` を拡張するものですので、フィクスチャによって提供されたデータに対して、次の構文を使ってアクセスすることも出来ます。
+さらには、`UserProfileFixture` は `ActiveFixture` を拡張するものですので、フィクスチャによって提供されたデータに対して、
+次の構文を使ってアクセスすることも出来ます。
 
 ```php
 // 'user1' というエイリアスのデータ行に対応する UserProfileModel を返す
@@ -195,7 +196,6 @@ data\
 
 このようにして、テスト間でフィクスチャのデータ・ファイルが衝突するのを回避し、必要に応じてデータ・ファイルを使い分けます。
 
-
 > Note: 上の例では、フィクスチャ・ファイルには例示目的だけの名前が付けられています。
 > 実際の仕事では、フィクスチャ・クラスがどのフィクスチャ・クラスを拡張したものであるかに従って名前を付けるべきです。
 > 例えば、DB フィクスチャを [[yii\test\ActiveFixture]] から拡張している場合は、DB テーブルの名前をフィクスチャのデータ・ファイル名として使うべきです。
@@ -217,8 +217,7 @@ Yii は `yii fixture` コマンドライン・ツールでフィクスチャを
 次のようなフィクスチャ・データをロードするとしましょう。
 
 ```
-# users.php ファイル
-# フィクスチャ・データ・パス (デフォルトでは @tests\unit\fixtures\data) に保存されている
+# users.php ファイル - フィクスチャ・データ・パス (デフォルトでは @tests\unit\fixtures\data) に保存
 
 return [
     [
@@ -237,33 +236,26 @@ return [
     ],
 ];
 ```
-
-データベースにデータをロードするフィクチャを使う場合は、これらの行が `users` テーブルに対して適用されます。
-NoSQL フィクスチャ、例えば `mongodb` フィクチャを使う場合は、このデータは `users` コレクションに対して適用されます。
+データベースにデータをロードするフィクチャを使う場合は、これらの行が `users` テーブルに対して適用されます。NoSQL フィクスチャ、例えば `mongodb` フィクチャを使う場合は、このデータは `users` コレクションに対して適用されます。
 さまざまなロード戦略を実装する方法などについて公式 [ドキュメント](https://github.com/yiisoft/yii2/blob/master/docs/guide/test-fixtures.md)を参照して下さい。
 上記のフィクスチャのサンプルは `yii2-faker` エクステンションによって生成されました。これについての詳細は、[自動生成のセクション](#auto-generating-fixtures) を参照して下さい。
-
 フィクスチャ・クラスの名前は複数形であってはいけません。
 
 ### フィクスチャをロードする
 
-フィクスチャ・クラスは `Fixture` という接尾辞を持たなければいけません。
-デフォルトでは、フィクスチャは `tests\unit\fixtures` 名前空間の下で探されます。
-この挙動は構成またはコマンド・オプションによって変更することが出来ます。
-`-User` のように名前の前に `-` を指定することで、ロードまたはアンロードから除外するフィクスチャを指定することが出来ます。
+フィクスチャ・クラスは `Fixture` という接尾辞を持たなければいけません。デフォルトでは、フィクスチャは `tests\unit\fixtures` 名前空間の下で探されます。
+この挙動は構成またはコマンド・オプションによって変更することが出来ます。`-User` のように名前の前に `-` を指定することで、ロードまたはアンロードから除外するフィクスチャを指定することが出来ます。
 
 フィクスチャをロードするためには、次のコマンドを実行します。
 
-> Note: データをロードする前に、アンロードのシーケンスが実行されます。これによって、通常は、前に実行されたフィクスチャによって挿入された
-  既存のデータが全てクリーンアップされることになります。
+> Note: データをロードする前に、アンロードのシーケンスが実行されます。これによって、通常は、前に実行されたフィクスチャによって挿入された 既存のデータが全てクリーンアップされることになります。
 
 ```
 yii fixture/load <fixture_name>
 ```
 
 要求される `fixture_name` パラメータが、データがロードされるフィクスチャの名前を指定するものです。
-いくつかのフィクスチャを一度にロードすることが出来ます。
-下記はこのコマンドの正しい形式です。
+いくつかのフィクスチャを一度にロードすることが出来ます。下記はこのコマンドの正しい形式です。
 
 ```
 // `User` フィクスチャをロードする
@@ -284,14 +276,11 @@ yii fixture "*"
 // 一つを除いて全てのフィクスチャをロードする
 yii fixture "*, -DoNotLoadThisOne"
 
-// 異なる名前空間からフィクスチャをロードする
-// デフォルトの名前空間は tests\unit\fixtures
+// 異なる名前空間からフィクスチャをロードする (デフォルトの名前空間は tests\unit\fixtures)
 yii fixture User --namespace='alias\my\custom\namespace'
 
-// 他のフィクスチャをロードする前に、グローバルフィクスチャ
-// `some\name\space\CustomFixture` をロードする。
-// デフォルトでは、このオプションが `InitDbFixture` について適用され、
-// 整合性チェックが無効化/有効化されます。
+// 他のフィクスチャをロードする前に、グローバルフィクスチャ `some\name\space\CustomFixture` をロードする。
+// デフォルトでは、このオプションが `InitDbFixture` について適用され、整合性チェックが無効化/有効化されます。
 // カンマで区切って複数のグローバル・フィクスチャを指定することが出来ます。
 yii fixture User --globalFixtures='some\name\space\Custom'
 ```
@@ -301,9 +290,7 @@ yii fixture User --globalFixtures='some\name\space\Custom'
 フィクスチャをアンロードするためには、次のコマンドを実行します。
 
 ```
-// Users フィクスチャをアンロードする。
-// デフォルトではフィクスチャのストレージをクリアします。
-// 例えば、"users" テーブル、または、mongodb フィクスチャなら "users" コレクションがクリアされます。
+// Users フィクスチャをアンロードする。デフォルトではフィクスチャのストレージをクリアします。(例えば、"users" テーブル、または、mongodb フィクスチャなら "users" コレクションがクリアされます。)
 yii fixture/unload User
 
 // いくつかのフィクスチャをアンロードする
@@ -340,8 +327,7 @@ yii fixture/unload "*, -DoNotUnloadThisOne"
 
 ### フィクスチャを自動生成する
 
-Yii は、あなたの代りに、何らかのテンプレートに従ってフィクスチャを自動生成することが出来ます。
-さまざまなデータで、また、いろいろな言語と形式で、フィクスチャを生成することが出来ます。
+Yii は、あなたの代りに、何らかのテンプレートに従ってフィクスチャを自動生成することが出来ます。さまざまなデータで、また、いろいろな言語と形式で、フィクスチャを生成することが出来ます。
 この機能は、[Faker](https://github.com/fzaninotto/Faker) ライブラリと `yii2-faker` エクステンションによって実現されています。
 詳細については、エクステンションの [ガイド](https://github.com/yiisoft/yii2-faker/tree/master/docs/guide-ja) を参照して下さい。.
 

docs/guide-ja/test-functional.md

@@ -6,7 +6,8 @@
 POST や GET のパラメータなどの環境変数を設定しておいてから、アプリケーションのインスタンスをコードから直接に実行します。
 
 機能テストは一般的に受入テストより高速であり、失敗した場合に詳細なスタックトレースを提供してくれます。
-経験則から言うと、特別なウェブ・サーバ設定や JavaScript による複雑な UI を持たない場合は、機能テストの方を選ぶべきです。
+経験則から言うと、特別なウェブ・サーバ設定や JavaScript による複雑な UI を持たない場合は、
+機能テストの方を選ぶべきです。
 
 機能テストは Codeception フレームワークの助けを借りて実装されています。これにつては、優れたドキュメントがあります。
 

docs/guide-ja/test-overview.md

@@ -6,21 +6,23 @@
 例えば、PHP でクラスを書くとき、私たちはステップごとにデバッグしたり、または単純に `echo` 文や `die` 文を使ったりして、実装が最初の計画通りに動作することを検証します。
 ウェブ・アプリケーションの場合は、何らかのテスト・データをフォームに入力して、ページが期待通りにユーザと相互作用をすることを確認します。
 
-テストを実行するプロセスを自動化して、何かを検証する必要があるときは、いつでも、それを代行してくれるコードを呼び出すだけでよいようにすることが出来ます。
+テストを実行するプロセスを自動化して、何かを検証する必要があるときは、いつでも、
+それを代行してくれるコードを呼び出すだけでよいようにすることが出来ます。
 結果が計画したものと合致することを検証するコードが *テスト* と呼ばれ、それを作成して更に実行するプロセスが *テスト自動化* として知られています。
 このテストの章の主題は、このテストの自動化です。
 
 
 ## テストとともに開発する
 
-テスト駆動開発 (TDD) とビヘイビア駆動開発 (BDD) のソフトウェア開発手法においては、実際のコードを書く前に、コードの断片または全体の機能の振る舞いを一連のシナリオまたはテストとして記述します。
-そして、その後で初めて、テストに合格するように実装を作成して、意図された振る舞いが達成されていることを検証します。
+テスト駆動開発 (TDD) とビヘイビア駆動開発 (BDD) のソフトウェア開発手法においては、実際のコードを書く前に、
+コードの断片または全体の機能の振る舞いを一連のシナリオまたはテストとして記述します。
+そして、その後で初めて、テストに合格するように実装を作成して、
+意図された振る舞いが達成されていることを検証します。
 
 一つの機能を開発するプロセスは以下のようになります。
 
 - 実装されるべき機能を記述するテストを作成する。
-- 新しいテストを走らせて、失敗することを確認する。
-  まだ実装がないので、これは予期された結果です。
+- 新しいテストを走らせて、失敗することを確認する。まだ実装がないので、これは予期された結果です。
 - 新しいテストに合格するための単純なコードを書く。
 - 全てのテストを走らせて、全てが合格することを確認する。
 - コードを改良して、それでも全てのテストが OK であることを確認する。
@@ -31,7 +33,8 @@
 > Tip: 多数の小さくて単純なイテレーションを繰り返すために時間を取られていると感じる場合は、テスト・シナリオのカバー範囲を広くして、テストを再度実行するまでの作業量を増やしてみてください。
 > デバッグばかりやっている場合は、逆に範囲を狭めてみてください。
 
-全ての実装作業の前にテストを作成する理由は、そうすれば、その後で、達成したい事柄に集中して「どのようにするか」に没頭することが出来るからです。
+全ての実装作業の前にテストを作成する理由は、そうすれば、その後で、
+達成したい事柄に集中して「どのようにするか」に没頭することが出来るからです。
 通常、そのようにすることは、良い抽象化、機能修正時の容易なテスト保守、また、結合度の低いコンポーネントにつながります。
 
 ですから、このような手法の長所を要約すると次のようになります。

docs/guide-ja/test-unit.md

@@ -5,8 +5,7 @@
 すなわち、さまざまな入力パラメータを与えて、クラスのメソッドが期待通りの結果を返すかどうかを検証します。
 単体テストは、通常は、テストされるクラスを書く人によって開発されます。
 
-Yii における単体テストは、PHPUnit と Codeception (こちらはオプションです) の上に構築されます。
-従って、それらのドキュメントを通読することが推奨されます。
+Yii における単体テストは、PHPUnit と Codeception (こちらはオプションです) の上に構築されます。従って、それらのドキュメントを通読することが推奨されます。
 
 - [Codeception for Yii framework](http://codeception.com/for/yii)
 - [Codeception Unit Tests](http://codeception.com/docs/05-UnitTests)
@@ -17,9 +16,9 @@ Yii における単体テストは、PHPUnit と Codeception (こちらはオプ
 アドバンスト・テンプレートでプロジェクトを開始した場合、テストの実行については、
 ["テスト" のガイド](https://github.com/yiisoft/yii2-app-advanced/blob/master/docs/guide-ja/start-testing.md) を参照して下さい。
 
-ベーシック・テンプレートでプロジェクトを開始した場合は、
-check its [README の "testing" のセクション](https://github.com/yiisoft/yii2-app-basic/blob/master/README.md#testing) を参照して下さい。
+ベーシック・テンプレートでプロジェクトを開始した場合は、[README の "testing" のセクション](https://github.com/yiisoft/yii2-app-basic/blob/master/README.md#testing) を参照して下さい。
 
 ## フレームワークの単体テスト
 
-Yii フレームワーク自体に対する単体テストを走らせたい場合は、"[Yii 2 の開発を始めよう](https://github.com/yiisoft/yii2/blob/master/docs/internals-ja/getting-started.md)" の説明に従ってください。
+Yii フレームワーク自体に対する単体テストを走らせたい場合は、"[Yii 2 の開発を始めよう](https://github.com/yiisoft/yii2/blob/master/docs/internals-ja/getting-started.md)"
+の説明に従ってください。