Merge pull request #6703 from softark/docs-guide-ja-test

Docs guide ja test [ci skip]

docs/guide-ja/README.md

@@ -150,12 +150,12 @@ RESTful ウェブサービス
 テスト
 ------
 
-* **翻訳未着手** [概要](test-overview.md)
-* **翻訳未着手** [テスト環境の構築](test-environment-setup.md)
-* **翻訳未着手** [ユニットテスト](test-unit.md)
-* **翻訳未着手** [機能テスト](test-functional.md)
-* **翻訳未着手** [承認テスト](test-acceptance.md)
-* **翻訳未着手** [フィクスチャ](test-fixtures.md)
+* [概要](test-overview.md)
+* [テスト環境の構築](test-environment-setup.md)
+* [ユニットテスト](test-unit.md)
+* [機能テスト](test-functional.md)
+* [承認テスト](test-acceptance.md)
+* **翻訳中** [フィクスチャ](test-fixtures.md)
 
 
 スペシャルトピック

docs/guide-ja/test-acceptance.md

@@ -0,0 +1,12 @@
+承認テスト
+==========
+
+> Note|注意: この節はまだ執筆中です。
+
+- http://codeception.com/docs/04-AcceptanceTests
+
+
+アプリケーションテンプレートの承認テストを走らせる
+--------------------------------------------------
+
+`apps/advanced/tests/README.md` および `apps/basic/tests/README.md` で提供されている説明を参照してください。

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

@@ -0,0 +1,31 @@
+テスト環境の構築
+================
+
+> Note|注意: この節はまだ執筆中です。
+
+Yii2 は [`Codeception`](https://github.com/Codeception/Codeception) テストフレームワークとの統合を公式にサポートしており、次のタイプのテストを作成することを可能にしています。
+
+- [ユニットテスト](test-unit.md) - 一つのコードユニットが期待通りに動くことを検証する。
+- [機能テスト](test-functional.md) - ブラウザのエミュレーションによって、ユーザの視点からシナリオを検証する。
+- [承認テスト](test-acceptance.md) - ブラウザの中で、ユーザの視点からシナリオを検証する。
+
+これら三つのタイプのテスト全てについて、Yii は、[`yii2-basic`](https://github.com/yiisoft/yii2/tree/master/apps/basic) と [`yii2-advanced`](https://github.com/yiisoft/yii2/tree/master/apps/advanced) の両方のテンプレートで、そのまま使えるテストセットを提供しています。
+
+テストを走らせるためには、[Codeception](https://github.com/Codeception/Codeception) をインストールする必要があります。
+インストールするのに良い方法は次のとおりです。
+
+```
+composer global require "codeception/codeception=2.0.*"
+composer global require "codeception/specify=*"
+composer global require "codeception/verify=*"
+```
+
+以前にグローバルパッケージのために Composer を使ったことが一度もない場合は、`composer global status` を実行してください。
+次のように出力される筈です。
+
+```
+Changed current directory to <directory>
+```
+
+そうしたら、`<directory>/vendor/bin` をあなたの `PATH` 環境変数に追加してください。
+これでコマンドラインから `codecept` をグローバルに使うことが出来ます。

docs/guide-ja/test-functional.md

@@ -0,0 +1,11 @@
+機能テスト
+==========
+
+> Note|注意: この節はまだ執筆中です。
+
+- http://codeception.com/docs/05-FunctionalTests
+
+アプリケーションテンプレートの機能テストを走らせる
+--------------------------------------------------
+
+`apps/advanced/tests/README.md` および `apps/basic/tests/README.md` で提供されている説明を参照してください。

docs/guide-ja/test-overview.md

@@ -0,0 +1,72 @@
+テスト
+======
+
+テストはソフトウェア開発の重要な部分です。
+気付いているか否かにかかわらず、私たちは継続的にテストをしています。
+例えば、PHP でクラスを書くとき、私たちはステップごとにデバッグしたり、または単純に echo 文や die 文を使ったりして、実装が最初の計画通りに動作することを確認します。
+ウェブアプリケーションの場合は、何らかのテストデータをフォームに入力して、ページがユーザと期待通りの相互作用をすることを確認します。
+テストを実行するプロセスを自動化して、何かを確認する必要があるときは、いつでも、それを代行してくれるコードを呼び出す必要があるだけにすることが出来ます。
+結果が計画したものと合致することを確認するコードがテストと呼ばれ、それを作成して更に実行するプロセスがテスト自動化として知られています。
+このテストの章の主題は、このテストの自動化です。
+
+
+テストとともに開発する
+----------------------
+
+テスト駆動開発 (TDD) とビヘイビア駆動開発 (BDD) のソフトウェア開発手法においては、実際のコードを書く前に、コードの断片または全体の機能の振る舞いを一連のシナリオまたはテストとして記述します。
+そして、その後で初めて、意図された振る舞いが達成されていることを確認するテストに合格する実装を作成します。
+
+一つの機能を開発するプロセスは以下のようになります。
+
+- 実装されるべき機能を記述するテストを作成する。
+- 新しいテストを走らせて、失敗することを確認する。
+  まだ実装がないので、これは予期された結果です。
+- 新しいテストに合格するための単純なコードを書く。
+- 全てのテストを走らせて、全てが合格することを確認する。
+- コードを改良して、それでも全てのテストが OK であることを確認する。
+
+完了すれば、別の機能または改良のために、このプロセスを再び繰り返します。
+既存の機能が変更される場合は、テストも変更されなければなりません。
+
+> **Tip**: 多数の小さくて単純なイテレーションを繰り返すために時間を取られていると感じる場合は、テストシナリオのカバー範囲を広くして、テストを再度実行するまでの作業量を増やしてみてください。
+> デバッグばかりやっている場合は、逆に範囲を狭めてみてください。
+
+全ての実装作業の前にテストを作成する理由は、そうすれば、その後で、達成したい事柄に集中して「どのようにするか」に没頭することが出来るからです。
+通常、そのようにすることは、良い抽象化、機能修正時の容易なテスト保守、また、結合度の低いコンポーネントにつながります。
+
+ですから、このような手法の長所を要約すると次のようになります。
+
+- 一時に一つの事柄に集中できるため、計画と実装がより良いものになる。
+- より多くの機能をより詳細にテストでカバーできる。つまり、テストが OK なら何も問題がないと期待できる。
+
+通常は、長い期間で見れば、かなり時間を節約する効果があります。
+
+> **Tip**: ソフトウェアの要求仕様の取り纏めと対象事物のモデリングに関する原則について更に知りたい場合は、[ドメイン駆動設計 (DDD)](http://ja.wikipedia.org/wiki/%E3%83%89%E3%83%A1%E3%82%A4%E3%83%B3%E9%A7%86%E5%8B%95%E8%A8%AD%E8%A8%88) を学習するのが良いでしょう。
+
+いつ、どうやって、テストするか
+------------------------------
+
+上記で説明したテストファーストの手法は長期間にわたる比較的複雑なプロジェクトには合理的なものですが、簡単なプロジェクトでは、やりすぎとなるおそれもあります。
+この手法が適切であることを示す兆候は、いくつかあります。
+
+- プロジェクトは既に大きくて複雑である。
+- プロジェクトの要求仕様が複雑になってきている。プロジェクトが継続的に大きくなっている。
+- プロジェクトが長期にわたる予定である。
+- 失敗のコストが高すぎる。
+
+既存の実装の振る舞いをカバーするテストを作成することは、何も悪いことではありません。
+
+- プロジェクトはレガシーなもので、段階的な刷新が予定されている。
+- 従事すべきプロジェクトを得たが、それにはテストがなかった。
+
+どんな形式の自動化テストもやりすぎになる、という場合もあり得ます。
+
+- プロジェクトは単純で、この先も、複雑になる心配はない。
+- これ以上かかわることはない一時的なプロジェクトである。
+
+このような場合であっても、時間に余裕があれば、テストを自動化することは良いことです。
+
+参照
+----
+
+- Test Driven Development: By Example / Kent Beck. ISBN: 0321146530.

docs/guide-ja/test-unit.md

@@ -0,0 +1,26 @@
+ユニットテスト
+==============
+
+> Note|注意: この節はまだ執筆中です。
+
+ユニットテストは、一ユニットのコードが期待通りに動作することを検証するものです。
+オブジェクト指向プログラミングでは、最も基本的なコードのユニットはクラスです。
+ユニットテストで主として必要となることは、従って、クラスの全てのインタフェイスメソッドが正しく動作することを検証することです。
+すなわち、さまざまな入力パラメータに対して、テストはメソッドが期待通りの結果を返すかどうかを検証します。
+ユニットテストは、通常は、テストされるクラスを書く人によって開発されます。
+
+Yii におけるユニットテストは、PHPUnit と Codeception (こちらはオプションです) の上に構築されます。
+従って、それらのドキュメントを通読することが推奨されます。
+
+- [PHPUnit のドキュメントの第2章以降](http://phpunit.de/manual/current/en/writing-tests-for-phpunit.html).
+- [Codeception Unit Tests](http://codeception.com/docs/06-UnitTests).
+
+アプリケーションテンプレートのユニットテストを走らせる
+------------------------------------------------------
+
+`apps/advanced/tests/README.md` および `apps/basic/tests/README.md` で提供されている説明を参照してください。
+
+フレームワークのユニットテスト
+------------------------------
+
+Yii フレームワーク自体に対するユニットテストを走らせたい場合は、"[Getting started with Yii2 development](https://github.com/yiisoft/yii2/blob/master/docs/internals/getting-started.md)" に従ってください。