mirror of
https://github.com/yiisoft/yii.git
synced 2026-03-14 03:56:53 +01:00
105 lines
7.5 KiB
Plaintext
105 lines
7.5 KiB
Plaintext
テスト
|
|
========
|
|
|
|
> Note|注意: この章で説明するテストのサポートは Yii バージョン 1.1 以上が必要です。ですが、これは Yii 1.1.x を使用して開発したアプリケーションがテスト出来ないという事ではありません。あなたがテストを行うのに利用できる、[PHPUnit](http://www.phpunit.de/) や [SimpleTest](http://www.simpletest.org/) といった多くのすばらしいテストのフレームワークがあります。
|
|
|
|
テストはソフトウェア開発に必要不可欠です。それを承知しているか否かに関係なく、私たちがウェブアプリケーションを開発している時にはいつでもテストを行います。例えば、PHP でクラスを書いた時、実装したメソッドが正しい事を確認するために、`echo` や `die` といった文を使うかもしれません。また、複雑なHTMLフォームを含むウェブページを実装するとき、期待された動作を保障するために、いくつかのテストデータを入力するかもしれません。より高度な開発者は、テストが必要な際、毎回、コードを呼び出せば、コンピュータがテストを実行するように、テストを自動化するためのコードを書くでしょう。これは、この章のメイントピックで *自動化テスト* として知られています。
|
|
|
|
Yii が提供するテストサポートには、*ユニットテスト* と *機能テスト* が含まれます。
|
|
|
|
ユニットテストは、コードの 1 ユニットが期待した通りに動作するどうかを検証します。オブジェクト指向プログラミングでは、最も基本的なコード単位はクラスです。よって、ユニットテストでは、主にクラス内の各インターフェースメソッドが適切に動くかどうかを検証する必要があります。すなわち、異なった入力パラメーターを与えて、そのメソッドが期待された結果を返すかどうかを検証します。ユニットテストは通常、テストされるクラスを書いた人により開発されます。
|
|
|
|
機能テストは、（例えばブログシステムの投稿管理のような）機能が期待した通りに動作するどうかを検証します。
|
|
ユニットテストと比較すると、機能テストは、テストされる機能が、複数のクラスにまたがる場合が多いため、より高いレベルのテストとなります。機能テストは通常、システムの要件を良く知る人により開発されます。（開発者か品質管理技術者のどちらかであるかもしれません。）
|
|
|
|
|
|
テスト駆動開発
|
|
=======================
|
|
|
|
以下では、いわゆる [テスト駆動開発 (TDD)](http://ja.wikipedia.org/wiki/%E3%83%86%E3%82%B9%E3%83%88%E9%A7%86%E5%8B%95%E9%96%8B%E7%99%BA) での開発サイクルを示します。
|
|
|
|
1. 実装されるべき機能をカバーする新しいテストを作成します。機能がまだ実装されていないので、テストは最初の実行時に失敗すると予想されます。
|
|
2. 全てのテストを実行し、その新しいテストが確実に失敗するようにします。
|
|
3. その新しいテストに合格するようにコードを書きます。
|
|
4. 全てのテストを実行し、それらが全て合格するようにします。
|
|
5. コードをリファクタリングし、また、全てのテストが合格することを確認してください。
|
|
|
|
ステップ1から5を繰り返し、機能の実装を進めて行きます。
|
|
|
|
|
|
テスト環境構築
|
|
======================
|
|
|
|
テストには [PHPUnit](http://www.phpunit.de/) 3.3以上 と [Selenium Remote Control](http://seleniumhq.org/projects/remote-control/) 1.0以上が必要です。
|
|
PHPUnit と Selenium Remote Control のインストール方法については、これらのドキュメントを参照してください。
|
|
|
|
新しい Yii アプリケーションを `yiic webapp` コンソールコマンドで生成した場合、新しいテストが書込、実行を行うために下記するファイルとディレクトリが作成されます。
|
|
|
|
~~~
|
|
testdrive/
|
|
protected/ 保護されたアプリケーションファイルが含まれる
|
|
tests/ アプリケーションのテストが含まれる
|
|
fixtures/ データベース設定が含まれる
|
|
functional/ 機能テストが含まれる
|
|
unit/ ユニットテストが含まれる
|
|
report/ レポートが含まれる
|
|
bootstrap.php 最初に実行されるスクリプト
|
|
phpunit.xml PHPUnitの設定ファイル
|
|
WebTestCase.php ウェブベースの機能テストのためのベースクラス
|
|
~~~
|
|
|
|
As shown in the above, our test code will be mainly put into three directories: `fixtures`, `functional` and `unit`, and the directory `report` will be used to store the generated code coverage reports.
|
|
|
|
To execute tests (whether unit tests or functional tests), we can execute the following commands in a console window:
|
|
|
|
~~~
|
|
% cd testdrive/protected/tests
|
|
% phpunit functional/PostTest.php // executes an individual test
|
|
% phpunit --verbose functional // executes all tests under 'functional'
|
|
% phpunit --coverage-html ./report unit
|
|
~~~
|
|
|
|
In the above, the last command will execute all tests under the `unit` directory and generate a code-coverage report under the `report` directory. Note that [xdebug extension](http://www.xdebug.org/) must be installed and enabled in order to generate code-coverage reports.
|
|
|
|
|
|
Test Bootstrap Script
|
|
====================
|
|
|
|
Let's take a look what may be in the `bootstrap.php` file. This file is so special because it is like the [entry script](/doc/guide/basics.entry) and is the starting point when we execute a set of tests.
|
|
|
|
~~~
|
|
[php]
|
|
$yiit='path/to/yii/framework/yiit.php';
|
|
$config=dirname(__FILE__).'/../config/test.php';
|
|
require_once($yiit);
|
|
require_once(dirname(__FILE__).'/WebTestCase.php');
|
|
Yii::createWebApplication($config);
|
|
~~~
|
|
|
|
In the above, we first include the `yiit.php` file from the Yii framework, which initializes some global constants and includes necessary test base classes. We then creates a Web application instance using the `test.php` configuration file. If we check `test.php`, we shall find that it inherits from the `main.php` configuration file and adds a `fixture` application component whose class is [CDbFixtureManager]. We will describe fixtures in detail in the next section.
|
|
|
|
~~~
|
|
[php]
|
|
return CMap::mergeArray(
|
|
require(dirname(__FILE__).'/main.php'),
|
|
array(
|
|
'components'=>array(
|
|
'fixture'=>array(
|
|
'class'=>'system.test.CDbFixtureManager',
|
|
),
|
|
/* uncomment the following to provide test database connection
|
|
'db'=>array(
|
|
'connectionString'=>'DSN for test database',
|
|
),
|
|
*/
|
|
),
|
|
)
|
|
);
|
|
~~~
|
|
|
|
When we run tests that involve database, we should provide a test database so that the test execution does not interfere with normal development or production activities. To do so, we just need to uncomment the `db` configuration in the above and fill in the `connectionString` property with the DSN (data source name) to the test database.
|
|
|
|
With such a bootstrap script, when we run unit tests, we will have an application instance that is nearly the same as the one that serves for Web requests. The main difference is that it has the fixture manager and is using the test database.
|
|
|
|
|
|
<div class="revision">$Id: test.overview.txt 1440 2009-10-08 00:08:00Z qiang.xue $</div> |