mirror of
https://github.com/yiisoft/yii2.git
synced 2025-08-13 22:06:51 +08:00
docs/guide-ja updats [ci skip] (#15978) [skip ci]
This commit is contained in:
Nobuo Kihara
committed by
Alexander Makarov
Alexander Makarov
parent
ff5616f1ff
commit
c57637bf65
@ -8,8 +8,8 @@ All Rights Reserved.
|
||||
2014 (c) Yii Software LLC.
|
||||
|
||||
|
||||
前書き
|
||||
------
|
||||
導入
|
||||
----
|
||||
|
||||
* [Yii について](intro-yii.md)
|
||||
* [バージョン 1.1 からのアップグレード](intro-upgrade-from-v1.md)
|
||||
@ -18,6 +18,7 @@ All Rights Reserved.
|
||||
始めよう
|
||||
--------
|
||||
|
||||
* [何を知っている必要があるか](start-prerequisites.md)
|
||||
* [Yii をインストールする](start-installation.md)
|
||||
* [アプリケーションを走らせる](start-workflow.md)
|
||||
* [こんにちは、と言う](start-hello.md)
|
||||
@ -30,7 +31,7 @@ All Rights Reserved.
|
||||
アプリケーションの構造
|
||||
----------------------
|
||||
|
||||
* [概要](structure-overview.md)
|
||||
* [アプリケーションの構造の概要](structure-overview.md)
|
||||
* [エントリスクリプト](structure-entry-scripts.md)
|
||||
* [アプリケーション](structure-applications.md)
|
||||
* [アプリケーションコンポーネント](structure-application-components.md)
|
||||
@ -47,7 +48,7 @@ All Rights Reserved.
|
||||
リクエストの処理
|
||||
----------------
|
||||
|
||||
* [概要](runtime-overview.md)
|
||||
* [リクエストの処理の概要](runtime-overview.md)
|
||||
* [ブートストラップ](runtime-bootstrapping.md)
|
||||
* [ルーティングと URL 生成](runtime-routing.md)
|
||||
* [リクエスト](runtime-requests.md)
|
||||
@ -92,6 +93,7 @@ All Rights Reserved.
|
||||
* [ファイルをアップロードする](input-file-upload.md)
|
||||
* [表形式インプットのデータ収集](input-tabular-input.md)
|
||||
* [複数のモデルのデータを取得する](input-multiple-models.md)
|
||||
* [クライアントサイドで ActiveForm を拡張する](input-form-javascript.md)
|
||||
|
||||
|
||||
データの表示
|
||||
@ -109,7 +111,7 @@ All Rights Reserved.
|
||||
セキュリティ
|
||||
------------
|
||||
|
||||
* [概要](security-overview.md)
|
||||
* [セキュリティの概要](security-overview.md)
|
||||
* [認証](security-authentication.md)
|
||||
* [権限付与](security-authorization.md)
|
||||
* [パスワードを扱う](security-passwords.md)
|
||||
@ -121,7 +123,7 @@ All Rights Reserved.
|
||||
キャッシュ
|
||||
----------
|
||||
|
||||
* [概要](caching-overview.md)
|
||||
* [キャッシュの概要](caching-overview.md)
|
||||
* [データキャッシュ](caching-data.md)
|
||||
* [フラグメントキャッシュ](caching-fragment.md)
|
||||
* [ページキャッシュ](caching-page.md)
|
||||
@ -147,12 +149,13 @@ RESTful ウェブサービス
|
||||
|
||||
* [デバッグツールバーとデバッガ](https://github.com/yiisoft/yii2-debug/blob/master/docs/guide-ja/README.md)
|
||||
* [Gii を使ってコードを生成する](https://github.com/yiisoft/yii2-gii/blob/master/docs/guide-ja/README.md)
|
||||
* [API ドキュメントを生成する](https://github.com/yiisoft/yii2-apidoc)
|
||||
|
||||
|
||||
テスト
|
||||
------
|
||||
|
||||
* [概要](test-overview.md)
|
||||
* [テストの概要](test-overview.md)
|
||||
* [テスト環境の構築](test-environment-setup.md)
|
||||
* [単体テスト](test-unit.md)
|
||||
* [機能テスト](test-functional.md)
|
||||
@ -173,6 +176,7 @@ RESTful ウェブサービス
|
||||
* [共有ホスティング環境](tutorial-shared-hosting.md)
|
||||
* [テンプレートエンジン](tutorial-template-engines.md)
|
||||
* [サードパーティのコードを扱う](tutorial-yii-integration.md)
|
||||
* [Yii をマイクロ・フレームワークとして使う](tutorial-yii-as-micro-framework.md)
|
||||
|
||||
|
||||
ウィジェット
|
||||
@ -193,7 +197,8 @@ RESTful ウェブサービス
|
||||
ヘルパ
|
||||
------
|
||||
|
||||
* [概要](helper-overview.md)
|
||||
* [ヘルパの概要](helper-overview.md)
|
||||
* [配列ヘルパ](helper-array.md)
|
||||
* [Html ヘルパ](helper-html.md)
|
||||
* [Url ヘルパ](helper-url.md)
|
||||
|
||||
|
||||
@ -55,7 +55,11 @@
|
||||
上述のように、アプリケーションコンポーネントは最初にアクセスされた時に初めてインスタンスが作成されます。
|
||||
リクエストの間に全くアクセスされなかった時は、インスタンスは作成されません。
|
||||
けれども、場合によっては、明示的にアクセスされないときでも、リクエストごとにアプリケーションコンポーネントのインスタンスを作成したいことがあります。
|
||||
そうするためには、アプリケーションの [[yii\base\Application::bootstrap|bootstrap]] プロパティのリストにそのコンポーネントの ID を挙げることが出来ます。
|
||||
そうするために、アプリケーションの [[yii\base\Application::bootstrap|bootstrap]] プロパティのリストにそのコンポーネントの ID を挙げることが出来ます。
|
||||
|
||||
また、特別なコンポーネントをブートストラップするためにクロージャを用いることも出来ます。
|
||||
インスタンス化されたコンポーネントを返すことは要求されません。
|
||||
単に [[yii\base\Application]] のインスタンス化の後にコードを走らせるだけのためにクロージャを使うことも出来ます。
|
||||
|
||||
例えば、次のアプリケーション構成情報は、`log` コンポーネントが常にロードされることを保証するものです。
|
||||
|
||||
@ -63,6 +67,13 @@
|
||||
[
|
||||
'bootstrap' => [
|
||||
'log',
|
||||
function($app){
|
||||
return new ComponentX();
|
||||
},
|
||||
function($app){
|
||||
// 何らかのコード
|
||||
return;
|
||||
}
|
||||
],
|
||||
'components' => [
|
||||
'log' => [
|
||||
|
||||
@ -40,6 +40,7 @@ class AppAsset extends AssetBundle
|
||||
public $baseUrl = '@web';
|
||||
public $css = [
|
||||
'css/site.css',
|
||||
['css/print.css', 'media' => 'print'],
|
||||
];
|
||||
public $js = [
|
||||
];
|
||||
@ -66,16 +67,17 @@ class AppAsset extends AssetBundle
|
||||
* [[yii\web\AssetBundle::baseUrl|baseUrl]]: [[yii\web\AssetBundle::basePath|basePath]] ディレクトリに対応する URL を指定します。
|
||||
[[yii\web\AssetBundle::basePath|basePath]] と同じように、[[yii\web\AssetBundle::sourcePath|sourcePath]] プロパティをセットした場合は、[アセットマネージャ](#asset-manager) がアセットを発行して、その結果、このプロパティを上書きします。
|
||||
[パスエイリアス](concept-aliases.md) をここで使うことが出来ます。
|
||||
* [[yii\web\AssetBundle::js|js]]: このバンドルに含まれる JavaScript ファイルをリストする配列です。
|
||||
* [[yii\web\AssetBundle::css|css]]: このバンドルに含まれている CSS ファイルをリストする配列です。
|
||||
ディレクトリの区切りとしてフォワードスラッシュ "/" だけを使わなければならないことに注意してください。
|
||||
それぞれのファイルは、個別に、パス文字列、または、パス文字列と属性のタグと値を一緒に含む配列によって指定することが出来ます。
|
||||
* [[yii\web\AssetBundle::js|js]]: このバンドルに含まれる JavaScript ファイルをリストする配列です。
|
||||
この配列の形式は、[[yii\web\AssetBundle::css|css]] の配列の形式と同じです。
|
||||
それぞれの JavaScript ファイルは、以下の二つの形式のどちらかによって指定することが出来ます。
|
||||
- ローカルの JavaScript ファイルを表す相対パス (例えば `js/main.js`)。
|
||||
実際のファイルのパスは、この相対パスの前に [[yii\web\AssetManager::basePath]] を付けることによって決定されます。
|
||||
また、実際の URL は、この相対パスの前に [[yii\web\AssetManager::baseUrl]] を付けることによって決定されます。
|
||||
- 外部の JavaScript ファイルを表す絶対 URL。
|
||||
例えば、`http://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js` や `//ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js` など。
|
||||
* [[yii\web\AssetBundle::css|css]]: このバンドルに含まれる CSS ファイルをリストする配列です。
|
||||
この配列の形式は、[[yii\web\AssetBundle::js|js]] の形式と同じです。
|
||||
* [[yii\web\AssetBundle::depends|depends]]: このバンドルが依存しているアセットバンドルの名前をリストする配列です
|
||||
(バンドルの依存関係については、すぐ後で説明します)。
|
||||
* [[yii\web\AssetBundle::jsOptions|jsOptions]]: このバンドルにある *全て* の JavaScript ファイルについて、それを登録するときに呼ばれる [[yii\web\View::registerJsFile()]] メソッドに渡されるオプションを指定します。
|
||||
@ -126,7 +128,8 @@ class AppAsset extends AssetBundle
|
||||
これらのプロパティの値は、[ビュー](structure-views.md) が CSS と JavaScript ファイルをインクルードするために、[[yii\web\View::registerCssFile()]] および [[yii\web\View::registerJsFile()]] メソッドを呼ぶときに、それぞれ、オプションとして引き渡されます。
|
||||
|
||||
> Note: バンドルクラスでセットしたオプションは、バンドルの中の *全て* の CSS/JavaScript ファイルに適用されます。
|
||||
いろいろなファイルに別々のオプションを使用したい場合は、別々のアセットバンドルを作成して、個々のバンドルの中では、一組のオプションを使うようにしなければなりません。
|
||||
いろいろなファイルに別々のオプションを使用したい場合は、上述した [[yii\web\AssetBundle::css|css] の形式を使うか、
|
||||
または、別々のアセットバンドルを作成して、個々のバンドルの中では、一組のオプションを使うようにしなければなりません。
|
||||
|
||||
例えば、IE9 以下のブラウザに対して CSS ファイルを条件的にインクルードするために、次のオプションを使うことが出来ます。
|
||||
|
||||
@ -173,8 +176,8 @@ class FontAwesomeAsset extends AssetBundle
|
||||
];
|
||||
public $publishOptions = [
|
||||
'only' => [
|
||||
'fonts/',
|
||||
'css/',
|
||||
'fonts/*',
|
||||
'css/*',
|
||||
]
|
||||
];
|
||||
}
|
||||
@ -184,14 +187,85 @@ class FontAwesomeAsset extends AssetBundle
|
||||
発行オプション `only` を指定して、`fonts` と `css` サブディレクトリだけが発行されるようにしています。
|
||||
|
||||
|
||||
### Bower と NPM のアセット <span id="bower-npm-assets"></span>
|
||||
### Bower と NPM のアセットのインストール <span id="bower-npm-assets"></span>
|
||||
|
||||
ほとんどの JavaScript/CSS パッケージは、[Bower](http://bower.io/) および/または [NPM](https://www.npmjs.org/) によって管理されています。
|
||||
あなたのアプリケーションやエクステンションがそのようなパッケージを使っている場合は、以下のステップに従って、ライブラリの中のアセットを管理することが推奨されます。
|
||||
PHP の世界には PHP の依存を管理する Composer がありますが、PHP のパッケージと全く同じように
|
||||
`composer.json` を使って Bower のパッケージも NPM のパッケージもロードすることが可能です。
|
||||
|
||||
このことを達成するために Composer の構成を少し修正しなければなりません。二つの方法があります。
|
||||
|
||||
___
|
||||
|
||||
##### asset-packagist レポジトリを使う
|
||||
|
||||
この方法は NPM または Bower のパッケージを必要とするプロジェクトの大半の要求を満たすことが出来ます。
|
||||
|
||||
> Note: 2.0.13 以降、ベーシック・アプリケーション・テンプレートとアドバンスト・アプリケーション・テンプレートはともに、
|
||||
デフォルトで asset-packagist を使うように前もって構成されていますので、
|
||||
この節は読み飛ばすことが出来ます。
|
||||
|
||||
プロジェクトの `composer.json` に、下記を追加します。
|
||||
|
||||
```json
|
||||
"repositories": [
|
||||
{
|
||||
"type": "composer",
|
||||
"url": "https://asset-packagist.org"
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
[アプリケーション構成情報](concept-configurations.md) の `@npm` と `@bower` の [エイリアス](concept-aliases.md) を修正します。
|
||||
|
||||
```php
|
||||
$config = [
|
||||
...
|
||||
'aliases' => [
|
||||
'@bower' => '@vendor/bower-asset',
|
||||
'@npm' => '@vendor/npm-asset',
|
||||
],
|
||||
...
|
||||
];
|
||||
```
|
||||
|
||||
asset-packagist がどのようにして動作するのかは、[asset-packagist.org のサイト](https://asset-packagist.org) に説明があります。
|
||||
|
||||
##### fxp/composer-asset-plugin を使う
|
||||
|
||||
asset-packagist と異なって、composer-asset-plugin はアプリケーション構成の変更を少しも要求しません。
|
||||
その代りに、次のコマンドを実行して特別な Composer プラグインをグローバルにインストールすることが要求されます。
|
||||
|
||||
```bash
|
||||
composer global require "fxp/composer-asset-plugin:^1.4.1"
|
||||
```
|
||||
|
||||
このコマンドによって [composer asset plugin](https://github.com/francoispluchino/composer-asset-plugin/) がグローバルにインストールされ、
|
||||
Bower と NPM パッケージの依存関係を Composer によって管理することが出来るようになります。
|
||||
プラグインがインストールされた後は、あなたのコンピュータ上の全てのプロジェクトが `composer.json` を通じて Bower と NPM パッケージをサポートすることが出来ます。
|
||||
|
||||
Yii を使ってこれらのアセットを発行したい場合は、プロジェクトの `composer.json` に下記を追加して、
|
||||
インストールされるパッケージが配置されるディレクトリを調整します。
|
||||
|
||||
```json
|
||||
"extra": {
|
||||
"asset-installer-paths": {
|
||||
"npm-asset-library": "vendor/npm",
|
||||
"bower-asset-library": "vendor/bower"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
> Note: `fxp/composer-asset-plugin` は、asset-packagist に比べて、`composer update` コマンドを著しく遅くします。
|
||||
|
||||
____
|
||||
|
||||
Composer で Bower と NPM をサポートできるように構成した後は:
|
||||
|
||||
1. アプリケーションまたはエクステンションの `composer.json` ファイルを修正して、パッケージを `require` のエントリに入れます。
|
||||
ライブラリを参照するのに、`bower-asset/PackageName` (Bower パッケージ) または `npm-asset/PackageName` (NPM パッケージ) を使わなければなりません。
|
||||
2. アセットバンドルクラスを作成して、アプリケーションまたはエクステンションで使う予定の JavaScript/CSS ファイルをリストに挙げます。
|
||||
2. `composer update` を実行します。
|
||||
3. アセットバンドルクラスを作成して、アプリケーションまたはエクステンションで使う予定の JavaScript/CSS ファイルをリストに挙げます。
|
||||
[[yii\web\AssetBundle::sourcePath|sourcePath]] プロパティは、`@bower/PackageName` または `@npm/PackageName` としなければなりません。
|
||||
これは、Composer が Bower または NPM パッケージを、このエイリアスに対応するディレクトリにインストールするためです。
|
||||
|
||||
@ -428,6 +502,30 @@ return [
|
||||
この方がファイルのコピーより速く、また、発行されたアセットが常に最新であることを保証することも出来ます。
|
||||
|
||||
|
||||
### キャッシュの廃棄 <span id="cache-busting"></span>
|
||||
|
||||
運用モードで動作しているウェブ・アプリケーションでは、アセットなどの静的なリソースに対する HTTP キャッシュを有効にするのが通例です。
|
||||
この慣行の難点は、アセットを修正して運用サーバに配備したときに、ユーザのクライアントが HTTP キャッシュのせいで古いバージョンを使い続けるおそれが常にあるという点です。
|
||||
この難点を克服するために、キャッシュ廃棄機能を使うことが出来ます。
|
||||
これはバージョン 2.0.3 で導入された機能で、[[yii\web\AssetManager]] を下記のように構成することで有効になります。
|
||||
|
||||
```php
|
||||
return [
|
||||
// ...
|
||||
'components' => [
|
||||
'assetManager' => [
|
||||
'appendTimestamp' => true,
|
||||
],
|
||||
],
|
||||
];
|
||||
```
|
||||
|
||||
このようにすると、全ての発行されたアセットの URL の末尾に最終更新日時のタイムスタンプが追加されます。
|
||||
例えば、`yii.js` に対する URL は `/assets/5515a87c/yii.js?v=1423448645"` のようなものになります。
|
||||
パラメータ `v` が `yii.js` ファイルの最終更新日時のタイムスタンプを表しています。
|
||||
これで、あなたがアセットを修正したときには、その URL も変更され、クライアントに最新バージョンのアセットを強制的に取得させることが出来ます。
|
||||
|
||||
|
||||
## よく使われるアセットバンドル <span id="common-asset-bundles"></span>
|
||||
|
||||
コアの Yii コードは多くのアセットバンドルを定義しています。
|
||||
|
||||
@ -165,6 +165,15 @@ yii <module_id>/<command>/<sub_command>
|
||||
ルートがモジュール ID だけを含む場合は、[[yii\base\Module::defaultRoute]] プロパティ (デフォルト値は `default` です) が、どのコントローラ/アクションが使用されるべきかを決定します。
|
||||
これは、`forum` というルートは `forum` モジュール内の `default` コントローラを表すという意味です。
|
||||
|
||||
モジュールのための URL マネージャの規則は [[yii\web\UrlManager::parseRequest()]] が起動される前に追加されなくてはなりません。
|
||||
すなわち、モジュールの `init()` の中で規則を追加しても動作しない、ということです。
|
||||
なぜなら、モジュールの初期化はルートの処理が済んだ後になるからです。
|
||||
従って、RUL 規則は [ブートストラップ段階](structure-extensions.md#bootstrapping-classes) で追加される必要があります。
|
||||
また、モジュールの URL 規則を [[\yii\web\GroupUrlRule]] に入れるのも良い方法です。
|
||||
|
||||
モジュールが [バージョン管理された API](rest-versioning.md) で使用される場合は、その URL 規則はアプリケーション構成情報の
|
||||
`urlManager` のセクションに直接に追加されなければなりません。
|
||||
|
||||
|
||||
### モジュールにアクセスする <span id="accessing-modules"></span>
|
||||
|
||||
@ -259,6 +268,38 @@ class Module extends \yii\base\Module
|
||||
[[yii\base\Application::loadedModules]] プロパティがロードされた全てのモジュールのリストを保持しています。
|
||||
このリストには、直接の子と孫以下の両方のモジュールが含まれ、クラス名によってインデックスされています。
|
||||
|
||||
## モジュール内からコンポーネントにアクセスする
|
||||
|
||||
バージョン 2.0.13 以降、モジュールは [ツリー走査](concept-service-locator.md#tree-traversal) をサポートしています。
|
||||
これによって、モジュールの開発者は(アプリケーション)コンポーネントを参照するのに、サービスロケータとして自身のモジュールを使うことが出来るようになりました。
|
||||
これが意味することは、`Yii::$app->get('db')` よりも `$module->get('db')` を使う方が良い、ということです。
|
||||
モジュールのユーザは、異なるコンポーネント(構成)が要求される場合は、モジュールで使用する特定のコンポーネントを指定することが出来ます。
|
||||
|
||||
例えば、次のような部分的なアプリケーション構成が可能です。
|
||||
|
||||
```php
|
||||
'components' => [
|
||||
'db' => [
|
||||
'tablePrefix' => 'main_',
|
||||
'class' => Connection::class,
|
||||
'enableQueryCache' => false
|
||||
],
|
||||
],
|
||||
'modules' => [
|
||||
'mymodule' => [
|
||||
'components' => [
|
||||
'db' => [
|
||||
'tablePrefix' => 'module_',
|
||||
'class' => Connection::class
|
||||
],
|
||||
],
|
||||
],
|
||||
],
|
||||
```
|
||||
|
||||
アプリケーションのデータベーステーブルは `main_` という接頭辞を持つ一方で、
|
||||
モジュールのデータベーステーブルは `module_` という接頭辞を持ちます。
|
||||
上記の構成はマージされないということに注意して下さい。例えば、モジュールのコンポーネントではクエリキャッシュはデフォルト値に従って有効なままになります。
|
||||
|
||||
## ベストプラクティス <span id="best-practices"></span>
|
||||
|
||||
|
||||
@ -33,9 +33,7 @@ use yii\jui\DatePicker;
|
||||
'model' => $model,
|
||||
'attribute' => 'from_date',
|
||||
'language' => 'ja',
|
||||
'clientOptions' => [
|
||||
'dateFormat' => 'yy-mm-dd',
|
||||
],
|
||||
'dateFormat' => 'php:Y-m-d',
|
||||
]) ?>
|
||||
```
|
||||
|
||||
|
||||
@ -1,12 +1,18 @@
|
||||
受入テスト
|
||||
==========
|
||||
|
||||
> Note: この節はまだ執筆中です。
|
||||
受入テストはユーザの視点からシナリオを検証するものです。
|
||||
テストされるアプリケーションは PhpBrowser または実際のブラウザによってアクセスされます。
|
||||
どちらの場合でも、ブラウザは HTTP によって通信しますので、アプリケーションはウェブサーバによってホストされる必要があります。
|
||||
|
||||
受入テストは Codeception フレームワークの助けを借りて実装されています。Codeception フレームワークには優れたドキュメントがありますので、参照して下さい。
|
||||
|
||||
- [Codeception for Yii framework](http://codeception.com/for/yii)
|
||||
- [Codeception Acceptance Tests](http://codeception.com/docs/03-AcceptanceTests)
|
||||
|
||||
## ベーシックテンプレート、アドバンストテンプレートのテストを実行する
|
||||
|
||||
アプリケーションテンプレートの受入テストを走らせる
|
||||
--------------------------------------------------
|
||||
アドバンストテンプレートで開発をしている場合は、テスト実行の詳細について、
|
||||
["テスト" のガイド](https://github.com/yiisoft/yii2-app-advanced/blob/master/docs/guide-ja/start-testing.md) を参照して下さい。
|
||||
|
||||
`apps/advanced/tests/README.md` および `apps/basic/tests/README.md` で提供されている説明を参照してください。
|
||||
ベーシックテンプレートで開発をしている場合は、[README の "testing" の節](https://github.com/yiisoft/yii2-app-basic/blob/master/README.md#testing) を参照して下さい。
|
||||
|
||||
@ -1,8 +1,6 @@
|
||||
テスト環境の構築
|
||||
================
|
||||
|
||||
> Note: この節はまだ執筆中です。
|
||||
|
||||
Yii 2 は [`Codeception`](https://github.com/Codeception/Codeception) テストフレームワークとの統合を公式にサポートしており、次のタイプのテストを作成することを可能にしています。
|
||||
|
||||
- [単体テスト](test-unit.md) - 一かたまりのコードが期待通りに動くことを検証する。
|
||||
@ -11,36 +9,11 @@ Yii 2 は [`Codeception`](https://github.com/Codeception/Codeception) テスト
|
||||
|
||||
これら三つのタイプのテスト全てについて、Yii は、[`yii2-basic`](https://github.com/yiisoft/yii2-app-basic) と [`yii2-advanced`](https://github.com/yiisoft/yii2-app-advanced) の両方のプロジェクトテンプレートで、そのまま使えるテストセットを提供しています。
|
||||
|
||||
テストを走らせるためには、[Codeception](https://github.com/Codeception/Codeception) をインストールする必要があります。
|
||||
Codeception は、特定のプロジェクトのためだけにローカルにインストールするか、開発マシンのためにグローバルにインストールするかを選ぶことが出来ます。
|
||||
|
||||
ローカルのインストールのためには、次のコマンドを使います。
|
||||
ベーシックテンプレート、アドバンストテンプレートの両方とも、Codeception がプリインストールされて付いて来ます。
|
||||
これらのテンプレートの一つを使っていない場合は、下記のコンソールコマンドを発行することで Codeception をインストールすることが出来ます。
|
||||
|
||||
```
|
||||
composer require "codeception/codeception=2.1.*"
|
||||
composer require "codeception/specify=*"
|
||||
composer require "codeception/verify=*"
|
||||
composer require codeception/codeception
|
||||
composer require codeception/specify
|
||||
composer require codeception/verify
|
||||
```
|
||||
|
||||
グローバルのインストールのためには、`global` 命令を使う必要があります。
|
||||
|
||||
```
|
||||
composer global require "codeception/codeception=2.1.*"
|
||||
composer global require "codeception/specify=*"
|
||||
composer global require "codeception/verify=*"
|
||||
```
|
||||
|
||||
以前にグローバルパッケージのために Composer を使ったことが一度もない場合は、`composer global status` を実行してください。
|
||||
次のように出力される筈です。
|
||||
|
||||
```
|
||||
Changed current directory to <directory>
|
||||
```
|
||||
|
||||
そうしたら、`<directory>/vendor/bin` をあなたの `PATH` 環境変数に追加してください。
|
||||
これでコマンドラインから `codecept` をグローバルに使うことが出来ます。
|
||||
|
||||
> Note: グローバルにインストールすると、あなたの開発環境で扱っている全てのプロジェクトに対して Codeception を使うことが出来るようになります。
|
||||
パスを指定せずに `codecept` シェルコマンドをグローバルに走らせることが可能になります。
|
||||
しかしながら、例えば、二つのプロジェクトが異なるバージョンの Codeception のインストールを要求している場合など、この方法が不適切なこともあり得ます。
|
||||
話を単純にするために、このガイドで実行しているテストに関するシェルコマンドは、全て、Codeception がグローバルにインストールされていることを前提にしています。
|
||||
|
||||
@ -3,7 +3,8 @@
|
||||
|
||||
フィクスチャはテストの重要な部分です。
|
||||
フィクスチャの主な目的は、テストを期待されている方法で繰り返して実行できるように、環境を固定された既知の状態に設定することです。
|
||||
Yii は、フィクスチャを正確に定義して容易に使うことを可能にするフィクスチャフレームワークを提供しています。
|
||||
Yii は、Codeception でテストを実行する場合でも、単独でテストを実行する場合でも、
|
||||
フィクスチャを正確に定義して容易に使うことが出来るように、フィクスチャフレームワークを提供しています。
|
||||
|
||||
Yii のフィクスチャフレームワークにおける鍵となる概念は、いわゆる *フィクスチャオブジェクト* です。
|
||||
フィクスチャオブジェクトはテスト環境のある特定の側面を表現するもので、[[yii\test\Fixture]] またはその子クラスのインスタンスです。
|
||||
@ -15,8 +16,7 @@ Yii のフィクスチャフレームワークにおける鍵となる概念は
|
||||
そしてフィクスチャがアンロードされるときには、依存するフィクスチャはそのフィクスチャの後にアンロードされます。
|
||||
|
||||
|
||||
フィクスチャを定義する
|
||||
----------------------
|
||||
## フィクスチャを定義する
|
||||
|
||||
フィクスチャを定義するためには、[[yii\test\Fixture]] または [[yii\test\ActiveFixture]] を拡張して新しいクラスを作ります。
|
||||
前者は汎用目的のフィクスチャに最も適しています。
|
||||
@ -104,29 +104,35 @@ class UserProfileFixture extends ActiveFixture
|
||||
DB と関係しないフィクスチャ (例えば、何らかのファイルやディレクトリに関するフィクスチャ) を定義するためには、より汎用的な基底クラス [[yii\test\Fixture]] から拡張して、[[yii\test\Fixture::load()|load()]] と [[yii\test\Fixture::unload()|unload()]] のメソッドをオーバーライドすることが出来ます。
|
||||
|
||||
|
||||
フィクスチャを使用する
|
||||
----------------------
|
||||
## フィクスチャを使用する
|
||||
|
||||
[Codeception](http://codeception.com/) を使ってコードをテストしている場合は、フィクスチャのローディングとアクセスについては、
|
||||
内蔵されているサポートを使用することが出来ます。
|
||||
|
||||
[Codeception](http://codeception.com/) を使ってコードをテストしている場合は、フィクスチャのローディングとアクセスを内蔵でサポートしている `yii2-codeception` を使用することを検討すべきです。
|
||||
その他のテストフレームワークを使っている場合は、テストケースで [[yii\test\FixtureTrait]] を使って同じ目的を達することが出来ます。
|
||||
|
||||
次に `yii2-codeception` を使って `UserProfile` 単体テストを書く方法を説明します。
|
||||
次に、Codeception を使って `UserProfile` 単体テストクラスを書く方法を説明します。
|
||||
|
||||
[[yii\codeception\DbTestCase]] または [[yii\codeception\TestCase]] を拡張する単体テストクラスにおいて、どのフィクスチャを使用したいかを [[yii\test\FixtureTrait::fixtures()|fixtures()]] メソッドの中で宣言します。
|
||||
`\Codeception\Test\Unit` を拡張するあなたの単体テストクラスにおいて、 `_fixtures()` メソッドの中で使いたいフィクスチャを宣言するか、
|
||||
または、アクターの `haveFixtures()` メソッドを直接に使用します。
|
||||
例えば、
|
||||
|
||||
```php
|
||||
namespace app\tests\unit\models;
|
||||
|
||||
use yii\codeception\DbTestCase;
|
||||
|
||||
use app\tests\fixtures\UserProfileFixture;
|
||||
|
||||
class UserProfileTest extends DbTestCase
|
||||
{
|
||||
public function fixtures()
|
||||
class UserProfileTest extends \Codeception\Test\Unit
|
||||
{
|
||||
public function _fixtures()
|
||||
{
|
||||
return [
|
||||
'profiles' => UserProfileFixture::className(),
|
||||
'profiles' => [
|
||||
'class' => UserProfileFixture::className(),
|
||||
// フィクスチャデータは tests/_data/user.php に配置されている
|
||||
'dataFile' => codecept_data_dir() . 'user.php'
|
||||
],
|
||||
];
|
||||
}
|
||||
|
||||
@ -134,55 +140,35 @@ class UserProfileTest extends DbTestCase
|
||||
}
|
||||
```
|
||||
|
||||
`fixtures()` メソッドにリストされたメソッドは、テストケースの中のどのテストメソッドが走る前にも自動的にロードされ、テストメソッドが完了した後にアンロードされます。
|
||||
前に説明したように、フィクスチャがロードされるときには、それが依存するフィクスチャのすべてが最初に自動的にロードされます。
|
||||
`_fixtures()` メソッドにリストされたフィクスチャは、テストが実行される前に自動的にロードされます。
|
||||
前に説明したように、フィクスチャがロードされるときには、それが依存するフィクスチャのすべてが自動的に先にロードされます。
|
||||
上の例では、`UserProfileFixture` は `UserFixture` に依存しているので、テストクラスのどのテストメソッドを走らせるときでも、二つのフィクスチャが連続してロードされます。
|
||||
すなわち、最初に `UserFixture` がロードされ、次に `UserProfileFixture` がロードされます。
|
||||
|
||||
`fixtures()` でフィクスチャを指定するときは、クラス名あるいはフィクスチャを指す構成情報配列を使うことが出来ます。
|
||||
`_fixtures()` でフィクスチャを指定するときも、`haveFixtures()` でフィクスチャを指定するときも、
|
||||
クラス名あるいはフィクスチャを指す構成情報配列を使うことが出来ます。
|
||||
構成情報配列を使うと、フィクスチャがロードされるときのフィクスチャのプロパティをカスタマイズすることが出来ます。
|
||||
|
||||
また、フィクスチャにエイリアスを割り当てることも出来ます。
|
||||
上記の例では、`UserProfileFixture` に `profiles` というエイリアスが与えられています。
|
||||
そうすると、テストメソッドの中でエイリアスを使ってフィクスチャオブジェクトにアクセスすることが出来るようになります。
|
||||
例えば、`$this->profiles` が `UserProfileFixture` を返すことになります。
|
||||
例えば、
|
||||
|
||||
```php
|
||||
$profile = $I->grabFixture('profiles', 'user1');
|
||||
```
|
||||
は `UserProfileFixture` オブジェクトを返します。
|
||||
|
||||
さらには、`UserProfileFixture` は `ActiveFixture` を拡張するものですので、フィクスチャによって提供されたデータに対して、次の構文を使ってアクセスすることも出来ます。
|
||||
|
||||
```php
|
||||
// 'user1' というエイリアスのデータ行を返す
|
||||
$row = $this->profiles['user1'];
|
||||
// 'user1' というエイリアスのデータ行に対応する UserProfileModel を返す
|
||||
$profile = $this->profiles('user1');
|
||||
$profile = $I->grabFixture('profiles', 'user1');
|
||||
// フィクスチャにある全てのデータ行をたどる
|
||||
foreach ($this->profiles as $row) ...
|
||||
foreach ($I->grabFixture('profiles') as $profile) ...
|
||||
```
|
||||
|
||||
> Info: `$this->profiles` は依然として `UserProfileFixture` という型です。
|
||||
> 上記のアクセス機能は PHP マジックメソッドによって実装されています。
|
||||
|
||||
|
||||
グローバルフィクスチャを定義して使用する
|
||||
----------------------------------------
|
||||
|
||||
上記で説明されたフィクスチャは主として個別のテストケースによって使われます。
|
||||
たいていの場合、全てまたは多くのテストケースに適用されるグローバルなフィクスチャもいくつか必要になります。
|
||||
一例は、[[yii\test\InitDbFixture]] で、これは二つのことをします。
|
||||
|
||||
* `@app/tests/fixtures/initdb.php` に配置されたスクリプトを実行して、いくつかの共通の初期化作業を行う。
|
||||
* 他の DB フィクスチャをロードする前に、データベースの整合性チェックを無効化し、他の DB フィクスチャがアンロードされた後で、それを再び有効化する。
|
||||
|
||||
グローバルフィクスチャの使い方は、グローバルでないフィクスチャと同じです。
|
||||
違うところは、グローバルフィクスチャは `fixtures()` ではなく [[yii\codeception\TestCase::globalFixtures()]] で宣言するという点です。
|
||||
テストケースがフィクスチャをロードするときは、最初にグローバルフィクスチャをロードし、次にグローバルでないものをロードします。
|
||||
|
||||
デフォルトでは、[[yii\codeception\DbTestCase]] は `InitDbFixture` を `globalFixtures()` メソッドの中で既に宣言しています。
|
||||
このことは、どのテストの前にも何らかの初期化作業をしたい場合は、`@app/tests/fixtures/initdb.php` だけを触ればよいことを意味します。
|
||||
その必要がなければ、単にそれぞれの個別テストケースとそれに対応するフィクスチャの開発に専念することが出来ます。
|
||||
|
||||
|
||||
フィクスチャクラスとデータファイルを編成する
|
||||
--------------------------------------------
|
||||
## フィクスチャクラスとデータファイルを編成する
|
||||
|
||||
デフォルトでは、フィクスチャクラスは対応するデータファイルを探すときに、フィクスチャのクラスファイルを含むフォルダのサブフォルダである `data` フォルダの中を見ます。
|
||||
簡単なプロジェクトではこの規約に従うことができます。
|
||||
@ -211,56 +197,28 @@ data\
|
||||
|
||||
|
||||
> Note: 上の例では、フィクスチャファイルには例示目的だけの名前が付けられています。
|
||||
> 実際の現場では、フィクスチャクラスの拡張元である基底クラスに従って名前を付けるべきです。
|
||||
> 実際の仕事では、フィクスチャクラスがどのフィクスチャクラスを拡張したものであるかに従って名前を付けるべきです。
|
||||
> 例えば、DB フィクスチャを [[yii\test\ActiveFixture]] から拡張している場合は、DB テーブルの名前をフィクスチャのデータファイル名として使うべきです。
|
||||
> MongoDB フィクスチャを [[yii\mongodb\ActiveFixture]] から拡張している場合は、コレクション名をファイル名として使うべきです。
|
||||
|
||||
同様な階層は、フィクスチャクラスファイルを編成するのにも使うことが出来ます。
|
||||
`data` をルートディレクトリとして使うのでなく、データファイルとの衝突を避けるために `fixtures` をルートディレクトリとして使うのが良いでしょう。
|
||||
|
||||
## `yii fixture` でフィクスチャを管理する
|
||||
|
||||
まとめ
|
||||
------
|
||||
Yii は `yii fixture` コマンドラインツールでフィクスチャをサポートしています。以下の機能をサポートしています。
|
||||
|
||||
以上、フィクスチャを定義して使用する方法を説明しました。
|
||||
下記に、DB に関連したユニットテストを走らせる場合の典型的なワークフローをまとめておきます。
|
||||
* 異なるストレージ (RDBMS、NoSQL など) へのフィクスチャのロード
|
||||
* 様々な方法でのフィクスチャのアンロード (通常はストレージをクリア)
|
||||
* フィクスチャの自動生成およびランダムデータの投入
|
||||
|
||||
1. `yii migrate` ツールを使って、テストのデータベースを最新版にアップグレードする
|
||||
2. テストケースを走らせる
|
||||
- フィクスチャをロードする - 関係する DB テーブルをクリーンアップし、フィクスチャデータを投入する
|
||||
- 実際のテストを実行する
|
||||
- フィクスチャをアンロードする
|
||||
3. 全てのテストが完了するまで、ステップ 2 を繰り返す
|
||||
### フィクスチャのデータ形式
|
||||
|
||||
|
||||
(以下は削除または大幅に改稿される可能性が高いので、当面、翻訳を見合わせます)
|
||||
|
||||
**To be cleaned up below**
|
||||
|
||||
Managing Fixtures
|
||||
=================
|
||||
|
||||
> Note: This section is under development.
|
||||
>
|
||||
> todo: this tutorial may be merged with the above part of test-fixtures.md
|
||||
|
||||
Fixtures are important part of testing. Their main purpose is to populate you with data that needed by testing
|
||||
different cases. With this data using your tests becoming more efficient and useful.
|
||||
|
||||
Yii supports fixtures via the `yii fixture` command line tool. This tool supports:
|
||||
|
||||
* Loading fixtures to different storage such as: RDBMS, NoSQL, etc;
|
||||
* Unloading fixtures in different ways (usually it is clearing storage);
|
||||
* Auto-generating fixtures and populating it with random data.
|
||||
|
||||
Fixtures format
|
||||
---------------
|
||||
|
||||
Fixtures are objects with different methods and configurations, refer to official [documentation](https://github.com/yiisoft/yii2/blob/master/docs/guide/test-fixtures.md) on them.
|
||||
Lets assume we have fixtures data to load:
|
||||
次のようなフィクスチャデータをロードするとしましょう。
|
||||
|
||||
```
|
||||
#users.php file under fixtures data path, by default @tests\unit\fixtures\data
|
||||
# users.php ファイル
|
||||
# フィクスチャデータパス (デフォルトでは @tests\unit\fixtures\data) に保存されている
|
||||
|
||||
return [
|
||||
[
|
||||
@ -279,81 +237,93 @@ return [
|
||||
],
|
||||
];
|
||||
```
|
||||
If we are using fixture that loads data into database then these rows will be applied to `users` table. If we are using nosql fixtures, for example `mongodb`
|
||||
fixture, then this data will be applied to `users` mongodb collection. In order to learn about implementing various loading strategies and more, refer to official [documentation](https://github.com/yiisoft/yii2/blob/master/docs/guide/test-fixtures.md).
|
||||
Above fixture example was auto-generated by `yii2-faker` extension, read more about it in these [section](#auto-generating-fixtures).
|
||||
Fixture classes name should not be plural.
|
||||
|
||||
Loading fixtures
|
||||
----------------
|
||||
データベースにデータをロードするフィクチャを使う場合は、これらの行が `users` テーブルに対して適用されます。
|
||||
NoSQL フィクスチャ、例えば `mongodb` フィクチャを使う場合は、このデータは `users` コレクションに対して適用されます。
|
||||
さまざまなロード戦略を実装する方法などについて公式 [ドキュメント](https://github.com/yiisoft/yii2/blob/master/docs/guide/test-fixtures.md)を参照して下さい。
|
||||
上記のフィクスチャのサンプルは `yii2-faker` エクステンションによって生成されました。これについての詳細は、[自動生成の節](#auto-generating-fixtures) を参照して下さい。
|
||||
|
||||
Fixture classes should be suffixed by `Fixture` class. By default fixtures will be searched under `tests\unit\fixtures` namespace, you can
|
||||
change this behavior with config or command options. You can exclude some fixtures due load or unload by specifying `-` before its name like `-User`.
|
||||
フィクスチャクラスの名前は複数形であってはいけません。
|
||||
|
||||
To load fixture, run the following command:
|
||||
### フィクスチャをロードする
|
||||
|
||||
フィクスチャクラスは `Fixture` という接尾辞を持たなければいけません。
|
||||
デフォルトでは、フィクスチャは `tests\unit\fixtures` 名前空間の下で探されます。
|
||||
この挙動は構成またはコマンドオプションによって変更することが出来ます。
|
||||
`-User` のように名前の前に `-` を指定することで、ロードまたはアンロードから除外するフィクスチャを指定することが出来ます。
|
||||
|
||||
フィクスチャをロードするためには、次のコマンドを実行します。
|
||||
|
||||
> Note: データをロードする前に、アンロードのシーケンスが実行されます。これによって、通常は、前に実行されたフィクスチャによって挿入された
|
||||
既存のデータが全てクリーンアップされることになります。
|
||||
|
||||
```
|
||||
yii fixture/load <fixture_name>
|
||||
```
|
||||
|
||||
The required `fixture_name` parameter specifies a fixture name which data will be loaded. You can load several fixtures at once.
|
||||
Below are correct formats of this command:
|
||||
要求される `fixture_name` パラメータが、データがロードされるフィクスチャの名前を指定するものです。
|
||||
いくつかのフィクスチャを一度にロードすることが出来ます。
|
||||
下記はこのコマンドの正しい形式です。
|
||||
|
||||
```
|
||||
// load `User` fixture
|
||||
// `User` フィクスチャをロードする
|
||||
yii fixture/load User
|
||||
|
||||
// same as above, because default action of "fixture" command is "load"
|
||||
// 上記と同じ、"fixture" コマンドのデフォルトのアクションは "load" であるため
|
||||
yii fixture User
|
||||
|
||||
// load several fixtures
|
||||
// いくつかのフィクスチャをロードする
|
||||
yii fixture "User, UserProfile"
|
||||
|
||||
// load all fixtures
|
||||
// 全てのフィクスチャをロードする
|
||||
yii fixture/load "*"
|
||||
|
||||
// same as above
|
||||
// 同上
|
||||
yii fixture "*"
|
||||
|
||||
// load all fixtures except ones
|
||||
// 一つを除いて全てのフィクスチャをロードする
|
||||
yii fixture "*, -DoNotLoadThisOne"
|
||||
|
||||
// load fixtures, but search them in different namespace. By default namespace is: tests\unit\fixtures.
|
||||
// 異なる名前空間からフィクスチャをロードする
|
||||
// デフォルトの名前空間は tests\unit\fixtures
|
||||
yii fixture User --namespace='alias\my\custom\namespace'
|
||||
|
||||
// load global fixture `some\name\space\CustomFixture` before other fixtures will be loaded.
|
||||
// By default this option is set to `InitDbFixture` to disable/enable integrity checks. You can specify several
|
||||
// global fixtures separated by comma.
|
||||
// 他のフィクスチャをロードする前に、グローバルフィクスチャ
|
||||
// `some\name\space\CustomFixture` をロードする。
|
||||
// デフォルトでは、このオプションが `InitDbFixture` について適用され、
|
||||
// 整合性チェックが無効化/有効化されます。
|
||||
// カンマで区切って複数のグローバルフィクスチャを指定することが出来ます。
|
||||
yii fixture User --globalFixtures='some\name\space\Custom'
|
||||
```
|
||||
|
||||
Unloading fixtures
|
||||
------------------
|
||||
### フィクスチャをアンロードする
|
||||
|
||||
To unload fixture, run the following command:
|
||||
フィクスチャをアンロードするためには、次のコマンドを実行します。
|
||||
|
||||
```
|
||||
// unload Users fixture, by default it will clear fixture storage (for example "users" table, or "users" collection if this is mongodb fixture).
|
||||
// Users フィクスチャをアンロードする。
|
||||
// デフォルトではフィクスチャのストレージをクリアします。
|
||||
// 例えば、"users" テーブル、または、mongodb フィクスチャなら "users" コレクションがクリアされます。
|
||||
yii fixture/unload User
|
||||
|
||||
// Unload several fixtures
|
||||
// いくつかのフィクスチャをアンロードする
|
||||
yii fixture/unload "User, UserProfile"
|
||||
|
||||
// unload all fixtures
|
||||
// すべてのフィクスチャをアンロードする
|
||||
yii fixture/unload "*"
|
||||
|
||||
// unload all fixtures except ones
|
||||
// 一つを除いて全てのフィクスチャをアンロードする
|
||||
yii fixture/unload "*, -DoNotUnloadThisOne"
|
||||
|
||||
```
|
||||
|
||||
Same command options like: `namespace`, `globalFixtures` also can be applied to this command.
|
||||
このコマンドでも、`namespace` や `globalFixtures` という同じオプションを適用することが出来ます。
|
||||
|
||||
Configure Command Globally
|
||||
--------------------------
|
||||
While command line options allow us to configure the migration command
|
||||
on-the-fly, sometimes we may want to configure the command once for all. For example you can configure
|
||||
different migration path as follows:
|
||||
### コマンドをグローバルに構成する
|
||||
|
||||
コマンドラインオプションはフィクスチャコマンドをその場で構成することを可能にするものですが、
|
||||
コマンドを一度だけ構成して済ませたい場合もあります。
|
||||
例えば、次のように、異なるフィクスチャのパスを構成することが出来ます。
|
||||
|
||||
```
|
||||
'controllerMap' => [
|
||||
@ -368,9 +338,21 @@ different migration path as follows:
|
||||
]
|
||||
```
|
||||
|
||||
Auto-generating fixtures
|
||||
------------------------
|
||||
### フィクスチャを自動生成する
|
||||
|
||||
Yii also can auto-generate fixtures for you based on some template. You can generate your fixtures with different data on different languages and formats.
|
||||
These feature is done by [Faker](https://github.com/fzaninotto/Faker) library and `yii2-faker` extension.
|
||||
See extension [guide](https://github.com/yiisoft/yii2-faker) for more docs.
|
||||
Yii は、あなたの代りに、何らかのテンプレートに従ってフィクスチャを自動生成することが出来ます。
|
||||
さまざまなデータで、また、いろいろな言語と形式で、フィクスチャを生成することが出来ます。
|
||||
この機能は、[Faker](https://github.com/fzaninotto/Faker) ライブラリと `yii2-faker` エクステンションによって実現されています。
|
||||
詳細については、エクステンションの [ガイド](https://github.com/yiisoft/yii2-faker/tree/master/docs/guide-ja) を参照して下さい。.
|
||||
|
||||
## まとめ
|
||||
|
||||
以上、フィクスチャを定義して使用する方法を説明しました。
|
||||
下記に、DB に関連した単体テストを走らせる場合の典型的なワークフローをまとめておきます。
|
||||
|
||||
1. `yii migrate` ツールを使って、テストのデータベースを最新版にアップグレードする
|
||||
2. テストケースを走らせる
|
||||
- フィクスチャをロードする - 関係する DB テーブルをクリーンアップし、フィクスチャデータを投入する
|
||||
- 実際のテストを実行する
|
||||
- フィクスチャをアンロードする
|
||||
3. 全てのテストが完了するまで、ステップ 2 を繰り返す
|
||||
|
||||
@ -1,11 +1,21 @@
|
||||
機能テスト
|
||||
==========
|
||||
|
||||
> Note: この節はまだ執筆中です。
|
||||
機能テストはユーザの視点からシナリオを検証するものです。
|
||||
[受入テスト](test-acceptance.md) と似ていますが、HTTP によって通信する代りに、
|
||||
POST や GET のパラメータなどの環境変数を設定しておいてから、アプリケーションのインスタンスをコードから直接に実行します。
|
||||
|
||||
機能テストは一般的に受入テストより高速であり、失敗した場合に詳細なスタックトレースを提供してくれます。
|
||||
経験則から言うと、特別なウェブサーバ設定や JavaScript による複雑な UI を持たない場合は、機能テストの方を選ぶべきです。
|
||||
|
||||
機能テストは Codeception フレームワークの助けを借りて実装されています。これにつては、優れたドキュメントがあります。
|
||||
|
||||
- [Codeception for Yii framework](http://codeception.com/for/yii)
|
||||
- [Codeception Functional Tests](http://codeception.com/docs/04-FunctionalTests)
|
||||
|
||||
アプリケーションテンプレートの機能テストを走らせる
|
||||
--------------------------------------------------
|
||||
## ベーシックテンプレート、アドバンストテンプレートのテストを実行する
|
||||
|
||||
`apps/advanced/tests/README.md` および `apps/basic/tests/README.md` で提供されている説明を参照してください。
|
||||
アドバンストテンプレートで開発をしている場合は、テスト実行の詳細について、
|
||||
["テスト" のガイド](https://github.com/yiisoft/yii2-app-advanced/blob/master/docs/guide-ja/start-testing.md) を参照して下さい。
|
||||
|
||||
ベーシックテンプレートで開発をしている場合は、[README の "testing" の節](https://github.com/yiisoft/yii2-app-basic/blob/master/README.md#testing) を参照して下さい。
|
||||
|
||||
@ -11,8 +11,7 @@
|
||||
このテストの章の主題は、このテストの自動化です。
|
||||
|
||||
|
||||
テストとともに開発する
|
||||
----------------------
|
||||
## テストとともに開発する
|
||||
|
||||
テスト駆動開発 (TDD) とビヘイビア駆動開発 (BDD) のソフトウェア開発手法においては、実際のコードを書く前に、コードの断片または全体の機能の振る舞いを一連のシナリオまたはテストとして記述します。
|
||||
そして、その後で初めて、テストに合格するように実装を作成して、意図された振る舞いが達成されていることを検証します。
|
||||
@ -42,10 +41,7 @@
|
||||
|
||||
通常は、長い期間で見れば、かなり時間を節約する効果があります。
|
||||
|
||||
> 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) を学習するのが良いでしょう。
|
||||
|
||||
いつ、どうやって、テストするか
|
||||
------------------------------
|
||||
## いつ、どうやって、テストするか
|
||||
|
||||
上記で説明したテストファーストの手法は長期間にわたる比較的複雑なプロジェクトには合理的なものですが、簡単なプロジェクトでは、やりすぎとなるおそれもあります。
|
||||
この手法が適切であることを示す指標がいくつかあります。
|
||||
@ -67,7 +63,6 @@
|
||||
|
||||
ただ、このような場合であっても、時間に余裕があれば、テストを自動化することは良いことです。
|
||||
|
||||
参考
|
||||
----
|
||||
## 参考
|
||||
|
||||
- Test Driven Development: By Example / Kent Beck. ISBN: 0321146530.
|
||||
|
||||
@ -1,22 +1,18 @@
|
||||
単体テスト
|
||||
==========
|
||||
|
||||
> Note: この節はまだ執筆中です。
|
||||
|
||||
単体テストは、一かたまりのコードが期待通りに動作することを検証するものです。
|
||||
オブジェクト指向プログラミングでは、最も基本的なコードのかたまりはクラスです。
|
||||
単体テストで主として必要となることは、従って、クラスの全てのインタフェイスメソッドが正しく動作することを検証することです。
|
||||
つまり、テストは、さまざまな入力パラメータに対してメソッドが期待通りの結果を返すかどうかを検証します。
|
||||
すなわち、さまざまな入力パラメータを与えて、クラスのメソッドが期待通りの結果を返すかどうかを検証します。
|
||||
単体テストは、通常は、テストされるクラスを書く人によって開発されます。
|
||||
|
||||
Yii における単体テストは、PHPUnit と Codeception (こちらはオプションです) の上に構築されます。
|
||||
従って、それらのドキュメントを通読することが推奨されます。
|
||||
|
||||
- [Codeception for Yii framework](http://codeception.com/for/yii)
|
||||
- [Codeception Unit Tests](http://codeception.com/docs/05-UnitTests)
|
||||
- [PHPUnit のドキュメントの第2章以降](http://phpunit.de/manual/current/en/writing-tests-for-phpunit.html).
|
||||
- [Codeception Unit Tests](http://codeception.com/docs/05-UnitTests).
|
||||
|
||||
ベーシックおよびアドバンストのテンプレートのテストを実行する
|
||||
------------------------------------------------------------
|
||||
## ベーシックテンプレート、アドバンストテンプレートのテストを実行する
|
||||
|
||||
アドバンストテンプレートでプロジェクトを開始した場合、テストの実行については、
|
||||
["テスト" のガイド](https://github.com/yiisoft/yii2-app-advanced/blob/master/docs/guide-ja/start-testing.md) を参照して下さい。
|
||||
@ -24,8 +20,6 @@ Yii における単体テストは、PHPUnit と Codeception (こちらはオプ
|
||||
ベーシックテンプレートでプロジェクトを開始した場合は、
|
||||
check its [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)" の説明に従ってください。
|
||||
|
||||
@ -102,6 +102,54 @@ exit($exitCode);
|
||||
> yii <route> --appconfig=path/to/config.php ...
|
||||
> ```
|
||||
|
||||
コンソールコマンドの補完 <span id="console-command-completion"></span>
|
||||
---------------
|
||||
|
||||
シェルで作業をしている場合、コマンド引数の自動補完は便利なものです。
|
||||
2.0.11 以降、`./yii` コマンドは、内蔵で Bash および ZSH のために補完をサポートしています。
|
||||
|
||||
### Bash の補完
|
||||
|
||||
bash completion がインストールされていることを確認して下さい。
|
||||
ほとんどの bash のインストレーションでは、デフォルトで利用可能になっています。
|
||||
|
||||
補完スクリプトを `/etc/bash_completion.d/` に置いて下さい。
|
||||
|
||||
curl -L https://raw.githubusercontent.com/yiisoft/yii2/master/contrib/completion/bash/yii -o /etc/bash_completion.d/yii
|
||||
|
||||
一時的な利用の場合は、ファイルをカレントディレクトリに置いて、`source yii` でカレントセッションに読み込みます。
|
||||
グローバルにインストールした場合は、ターミナルを再起動するか、`source ~/.bashrc` を実行して、有効化する必要があります。
|
||||
|
||||
あなたの環境で補完スクリプトを読み込む他の方法については、
|
||||
[Bash マニュアル](https://www.gnu.org/software/bash/manual/html_node/Programmable-Completion.html) を参照して下さい。
|
||||
|
||||
### ZSH の補完
|
||||
|
||||
補完のためのディレクトリ、例えば `~/.zsh/completion/` に補完スクリプトを置いて下さい。
|
||||
|
||||
```
|
||||
mkdir -p ~/.zsh/completion
|
||||
curl -L https://raw.githubusercontent.com/yiisoft/yii2/master/contrib/completion/zsh/_yii -o ~/.zsh/completion/_yii
|
||||
```
|
||||
|
||||
そのディレクトリを `$fpath` に追加します。例えば `~/.zshrc` に次の記述を追加します。
|
||||
|
||||
```
|
||||
fpath=(~/.zsh/completion $fpath)
|
||||
```
|
||||
|
||||
`compinit` がロードされていることを確認して下さい。そうでなければ、`~/.zshrc` の中でロードします。
|
||||
|
||||
```
|
||||
autoload -Uz compinit && compinit -i
|
||||
```
|
||||
|
||||
そしてシェルをリロードします。
|
||||
|
||||
```
|
||||
exec $SHELL -l
|
||||
```
|
||||
|
||||
|
||||
あなた自身のコンソールコマンドを作成する <span id="create-command"></span>
|
||||
----------------------------------------
|
||||
@ -215,12 +263,21 @@ public function actionIndex()
|
||||
}
|
||||
```
|
||||
|
||||
いくつか使用できる事前定義された定数があります。
|
||||
いくつか使用できる事前定義された定数があります。それらは [[yii\console\ExitCode]] クラスで定義されています。
|
||||
|
||||
- [[yii\console\Controller::EXIT_CODE_NORMAL|Controller::EXIT_CODE_NORMAL]] - 値は `0`
|
||||
- [[yii\console\Controller::EXIT_CODE_ERROR|Controller::EXIT_CODE_ERROR]] - 値は `1`
|
||||
```php
|
||||
public function actionIndex()
|
||||
{
|
||||
if (/* 何らかの問題が発生 */) {
|
||||
echo "A problem occurred!\n";
|
||||
return ExitCode::UNSPECIFIED_ERROR;
|
||||
}
|
||||
// 何かをする
|
||||
return ExitCode::OK;
|
||||
}
|
||||
```
|
||||
|
||||
もっと多くのエラーコードの種類がある場合は、コントローラで意味のある定数を定義するのが良いプラクティスです。
|
||||
もっと詳細なエラーコードを必要とする場合は、コントローラで詳細な定数を定義するのが良いプラクティスです。
|
||||
|
||||
### 書式設定と色
|
||||
|
||||
@ -240,3 +297,20 @@ $this->stdout("Hello?\n", Console::BOLD);
|
||||
$name = $this->ansiFormat('Alex', Console::FG_YELLOW);
|
||||
echo "Hello, my name is $name.";
|
||||
```
|
||||
|
||||
### 表形式
|
||||
|
||||
バージョン 2.0.13 以降、表形式のデータをコンソールに表示するウィジェットが追加されています。
|
||||
次のようにして使うことが出来ます。
|
||||
|
||||
```php
|
||||
echo Table::widget([
|
||||
'headers' => ['Project', 'Status', 'Participant'],
|
||||
'rows' => [
|
||||
['Yii', 'OK', '@samdark'],
|
||||
['Yii', 'OK', '@cebe'],
|
||||
],
|
||||
]);
|
||||
```
|
||||
|
||||
詳細については [[yii\console\widgets\Table|API リファレンス]] を参照して下さい。
|
||||
|
||||
@ -188,7 +188,8 @@ function foo($model, $attribute) {
|
||||
```
|
||||
|
||||
> Info: 値が空であるか否かを決定する方法については、独立したトピックとして、[空の入力値を扱う](input-validation.md#handling-empty-inputs) の節でカバーされています。
|
||||
|
||||
データベーススキーマによるデフォルト値は、モデルの [loadDefaultValues()](db-active-record.md#default-attribute-values)
|
||||
によってロードすることが出来ます。
|
||||
|
||||
## [[yii\validators\NumberValidator|double]] <span id="double"></span>
|
||||
|
||||
@ -681,3 +682,7 @@ IPv4 アドレス `192.168.10.128` も、制約の前にリストされている
|
||||
IDN のバリデーションを使用するためには、`intl` PHP 拡張をインストールして有効化する必要があることに注意してください。
|
||||
そうしないと、例外が投げられます。
|
||||
|
||||
> Note: このバリデータは URL スキームとホスト部分が正しいものであることを検証します。
|
||||
URL の残りの部分はチェックしません。また、XSS や他の攻撃に対して防御するように設計されてもいません。
|
||||
アプリケーション開発における脅威に対する防御について更に学習するために
|
||||
[セキュリティのベストプラクティス](security-best-practices.md) を参照して下さい。
|
||||
|
||||
@ -175,6 +175,12 @@ Composer のオートローダは、ほとんどのサードパーティのク
|
||||
composer dumpautoload -o
|
||||
```
|
||||
|
||||
さらに加えて、
|
||||
[authoritative class maps](https://getcomposer.org/doc/articles/autoloader-optimization.md#optimization-level-2-a-authoritative-class-maps)
|
||||
および [APCu cache](https://getcomposer.org/doc/articles/autoloader-optimization.md#optimization-level-2-b-apcu-cache) の使用を検討して下さい。
|
||||
ただし、この二つの最適化があなたの特定のケースに適切である場合もあれば、そうでない場合もあります。
|
||||
|
||||
|
||||
## オフラインでデータを処理する <span id="processing-data-offline"></span>
|
||||
|
||||
リクエストが何らかのリソース集約的な操作を必要とするものである場合は、そういう操作が終るまでユーザを待たせずに、オフラインモードで操作を実行する方策を考えるべきです。
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
共有ホスティング環境
|
||||
====================
|
||||
|
||||
共有ホスティング環境では、たいてい、構成やディレクトリ構造について、大きな制約があります。
|
||||
共有ホスティング環境では、たいてい、構成やディレクトリ構造について大きな制約があります。
|
||||
それでも、ほとんどの場合、少し調整をすれば、Yii 2.0 を共有ホスティング環境で走らせることが可能です。
|
||||
|
||||
## ベーシックプロジェクトテンプレートを配備する
|
||||
|
||||
@ -48,4 +48,3 @@
|
||||
|
||||
- [Twig ガイド](https://github.com/yiisoft/yii2-twig/tree/master/docs/guide-ja)
|
||||
- [Smarty ガイド](https://github.com/yiisoft/yii2-smarty/tree/master/docs/guide-ja)
|
||||
|
||||
|
||||
217
docs/guide-ja/tutorial-yii-as-micro-framework.md
Normal file
217
docs/guide-ja/tutorial-yii-as-micro-framework.md
Normal file
@ -0,0 +1,217 @@
|
||||
# Yii をマイクロ・フレームワークとして使う
|
||||
|
||||
Yii はベーシックテンプレートやアドバンストテンプレートに含まれる機能なしで使うことが簡単にできます。
|
||||
言葉を換えれば、Yii は既にマイクロ・フレームワークです。
|
||||
Yii を使うためにテンプレートによって提供されているディレクトリ構造を持つことは要求されていません。
|
||||
|
||||
このことは、アセットやビューなどの事前定義されたテンプレートコードを必要としない場合には、特に好都合です。
|
||||
そのような場合の一つが JSON API です。以下に続く節で、どのようにしてそれを実現するかを示します。
|
||||
|
||||
## Yii をインストールする
|
||||
|
||||
プロジェクトファイルのためのディレクトリを作成し、ワーキングディレクトリをそのパスに変更します。
|
||||
例で使用されているコマンドは UNIX ベースのものですが、同様のコマンドが Windows にもあります。
|
||||
|
||||
```bash
|
||||
mkdir micro-app
|
||||
cd micro-app
|
||||
```
|
||||
|
||||
> Note: 続けるためには Composer についての知識が多少必要です。
|
||||
Composer の使い方をまだ知らない場合は、時間を取って、[Composer Guide](https://getcomposer.org/doc/00-intro.md) を読んでください。
|
||||
|
||||
`micro-app` ディレクトリの下に `composer.json` ファイルを作成し、あなたの好みのエディタを使って、下記を追加します。
|
||||
|
||||
```json
|
||||
{
|
||||
"require": {
|
||||
"yiisoft/yii2": "~2.0.0"
|
||||
},
|
||||
"repositories": [
|
||||
{
|
||||
"type": "composer",
|
||||
"url": "https://asset-packagist.org"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
ファイルを保存して `composer install` コマンドを実行します。これによって、フレームワークがその全ての依存とともにインストールされます。
|
||||
|
||||
## プロジェクトの構造を作成する
|
||||
|
||||
フレームワークをインストールしたら、次は、アプリケーションの [エントリポイント](structure-entry-scripts.md) を作成します。
|
||||
エントリポイントは、アプリケーションを開こうとしたときに、一番最初に実行されるファイルです。
|
||||
セキュリティ上の理由により、エントリポイントを置くディレクトリは別にして、それをウェブルートとします。
|
||||
|
||||
`web` ディレクトリを作成して、下記の内容を持つ `index.php` をそこに置きます。
|
||||
|
||||
```php
|
||||
<?php
|
||||
|
||||
// 実運用サーバに配備するときは次の2行をコメントアウトする
|
||||
defined('YII_DEBUG') or define('YII_DEBUG', true);
|
||||
defined('YII_ENV') or define('YII_ENV', 'dev');
|
||||
|
||||
require(__DIR__ . '/../vendor/autoload.php');
|
||||
require(__DIR__ . '/../vendor/yiisoft/yii2/Yii.php');
|
||||
|
||||
$config = require __DIR__ . '/../config.php';
|
||||
(new yii\web\Application($config))->run();
|
||||
```
|
||||
|
||||
また `config.php` という名前のファイルを作成し、アプリケーションの全ての構成情報をそこに含ませます。
|
||||
|
||||
```php
|
||||
<?php
|
||||
return [
|
||||
'id' => 'micro-app',
|
||||
// アプリケーションの basePath は `micro-app` ディレクトリになります
|
||||
'basePath' => __DIR__,
|
||||
// この名前空間からアプリケーションは全てのコントローラを探します
|
||||
'controllerNamespace' => 'micro\controllers',
|
||||
// 'micro' 名前空間からのクラスのオートロードを可能にするためにエイリアスを設定します
|
||||
'aliases' => [
|
||||
'@micro' => __DIR__,
|
||||
],
|
||||
];
|
||||
```
|
||||
|
||||
> Info: 構成情報を `index.php` ファイルに持つことも出来ますが、別のファイルに持つことを推奨します。
|
||||
> そうすれば、後で示しているように、同じ構成情報をコンソールアプリケーションから使うことが出来ます。
|
||||
|
||||
これであなたのプロジェクトはコーディングの準備が出来ました。
|
||||
プロジェクトのディレクトリ構造を決定するのは、名前空間に注意する限り、あなた次第です。
|
||||
|
||||
## 最初のコントローラを作成する
|
||||
|
||||
`controllers` ディレクトリを作成し、`SiteController.php` というファイルを追加します。
|
||||
これが、パス情報を持たないリクエストを処理する、デフォルトのコントローラです。
|
||||
|
||||
```php
|
||||
<?php
|
||||
|
||||
namespace micro\controllers;
|
||||
|
||||
use yii\web\Controller;
|
||||
|
||||
class SiteController extends Controller
|
||||
{
|
||||
public function actionIndex()
|
||||
{
|
||||
return 'こんにちは!';
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
このコントローラに違う名前を使いたい場合は、名前を変更して [[yii\base\Application::$defaultRoute]] をそれに応じて変更します。
|
||||
例えば、`DefaultController` であれば、`'defaultRoute' => 'default/index'` と変更します。
|
||||
|
||||
この時点で、プロジェクトの構造は次のようになっています。
|
||||
|
||||
```
|
||||
micro-app/
|
||||
├── composer.json
|
||||
├── config.php
|
||||
├── web/
|
||||
└── index.php
|
||||
└── controllers/
|
||||
└── SiteController.php
|
||||
```
|
||||
|
||||
まだウェブサーバをセットアップしていない場合は、[ウェブサーバの構成ファイル例](start-installation.md#configuring-web-servers) を参照すると良いでしょう。
|
||||
もう一つのオプションは、PHP の内蔵ウェブサーバを利用する `yii serve` コマンドを使うことです。`micro-app/` ディレクトリから、次のコマンドを実行します。
|
||||
|
||||
vendor/bin/yii serve --docroot=./web
|
||||
|
||||
アプリケーションの URL をブラウザで開くと、`SiteController::actionIndex()` で返された "こんにちは!" という文字列が表示される筈です。
|
||||
|
||||
> Info: 私たちの例では、アプリケーションのデフォルトの名前空間 `app` を `micro` に変更しています。
|
||||
> これは、あなたがその名前に縛られていないことを示すためです(万一あなたが縛られていると思っている場合を考えて)。
|
||||
> そして、[[yii\base\Application::$controllerNamespace|コントローラの名前空間]] を修正し、正しいエイリアスを設定しています。
|
||||
|
||||
|
||||
## REST API を作成する
|
||||
|
||||
私たちの "マイクロ・フレームワーク" の使い方を示すために、記事のための簡単な REST API を作成しましょう。
|
||||
`
|
||||
この API が何らかのデータを提供するためには、まず、データベースが必要です。
|
||||
データベース接続の構成をアプリケーション構成に追加します。
|
||||
|
||||
```php
|
||||
'components' => [
|
||||
'db' => [
|
||||
'class' => 'yii\db\Connection',
|
||||
'dsn' => 'sqlite:@micro/database.sqlite',
|
||||
],
|
||||
],
|
||||
```
|
||||
|
||||
> Info: ここでは話を簡単にするために sqlite データベースを使用します。他のオプションについては [データベースのガイド](db-dao.md) を参照してください。
|
||||
|
||||
次に、[データベースマイグレーション](db-migrations.md) を作成して、記事のテーブルを作成します。
|
||||
既に述べたように、独立した構成情報ファイルがあることを確認してください。下記のコンソールコマンドを実行するためには、それが必要です。
|
||||
次のコマンドを実行すると、データベースマイグレーションファイルが作成され、そして、マイグレーションがデータベースに適用されます。
|
||||
|
||||
vendor/bin/yii migrate/create --appconfig=config.php create_post_table --fields="title:string,body:text"
|
||||
vendor/bin/yii migrate/up --appconfig=config.php
|
||||
|
||||
`models` ディレクトリを作成し、`Post.php` ファイルをそのディレクトリに置きます。以下がそのモデルのためのコードです。
|
||||
|
||||
```php
|
||||
<?php
|
||||
|
||||
namespace micro\models;
|
||||
|
||||
use yii\db\ActiveRecord;
|
||||
|
||||
class Post extends ActiveRecord
|
||||
{
|
||||
public static function tableName()
|
||||
{
|
||||
return '{{post}}';
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
> Info: ここで作成されたモデルは ActiveRecord クラスのもので、`post` テーブルのデータを表します。
|
||||
> 詳細な情報は [アクティブレコードのガイド](db-active-record.md) を参照してください。
|
||||
|
||||
私たちの API で記事データへのアクセスを提供するために、`controllers` に `PostController` を追加します。
|
||||
|
||||
```php
|
||||
<?php
|
||||
|
||||
namespace micro\controllers;
|
||||
|
||||
use yii\rest\ActiveController;
|
||||
|
||||
class PostController extends ActiveController
|
||||
{
|
||||
public $modelClass = 'micro\models\Post';
|
||||
|
||||
public function behaviors()
|
||||
{
|
||||
// 動作のために認証済みユーザであることを要求する rateLimiter を削除
|
||||
$behaviors = parent::behaviors();
|
||||
unset($behaviors['rateLimiter']);
|
||||
return $behaviors;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
この時点で私たちの API は以下の URL を提供します。
|
||||
|
||||
- `/index.php?r=post` - 全ての記事をリストする
|
||||
- `/index.php?r=post/view&id=1` - ID 1 の記事を表示する
|
||||
- `/index.php?r=post/create` - 記事を作成する
|
||||
- `/index.php?r=post/update&id=1` - ID 1 の記事を更新する
|
||||
- `/index.php?r=post/delete&id=1` - ID 1 の記事を削除する
|
||||
|
||||
ここから開始して、あなたのアプリケーションの開発を更に進めるために、次のガイドを読むと良いでしょう。
|
||||
|
||||
- API は今のところ入力として URL エンコードされたフォームデータだけを理解します。
|
||||
本物の JSON API にするためには、[[yii\web\JsonParser]] を構成する必要があります。
|
||||
- URL をもっと馴染みやすいものにするためには、ルーティングを構成しなければなりません。
|
||||
方法を知るためには [REST のルーティングのガイド](rest-routing.md) を参照してください。
|
||||
- 更に参照すべき文書を知るために [先を見通す](start-looking-ahead.md) の節を読んでください。
|
||||
Reference in New Issue
Block a user