基本の考え方
命名規則とアノテーション
- テストクラスのファイル名は Test.php で終わる。
- メソッド名は test で始めるか、そうでない場合は
@test
アノテーションを DocComment 内に記述する。 - テストメソッドの DocComment 内に
@covers
アノテーションを書くと、テスト対象のメソッドを明示的に指定することができる。
*/
class SomeClassTest
{
/**
* @test
* @covers ::someMethod
*/
public function SomeMethodが正しく実行できること()
全体を実行する
# php artisan test
ユニットテストまたはフィーチャーテストのみを実行する
# php artisan test --testsuite=Unit
フィーチャーテストの場合は Unit
の代わりに Feature
を記述する。
特定のテストクラスのみを実行する
# php artisan test tests/Unit/ExampleTest.php
拡張子はなくても大丈夫。
特定のメソッドのみを実行する
# php artisan test tests/Unit/ExampleTest.php --filter=testBasicTest
ユニットテストとフィーチャーテストの扱いについて
<?php
namespace Tests;
use Illuminate\\Foundation\\Testing\\TestCase as BaseTestCase;
abstract class TestCase extends BaseTestCase
{
use CreatesApplication;
}
- tests/TestCase.phpの
CreatesApplication
トレイトを呼び出すことで、Facade の登録やコンフィグファイルの読み込みなどが行われる。つまり、Tests\TestCase クラスを継承することで Laravel の内部の機能にアクセスできるようになる。 - Tests\TestCase を継承しているのは Feature のほうだけで、Unit にあるほうは PHPUnit が提供している基底クラスを継承している。これは、Unitテストはフレームワークの機能に依存しない形で書くことが望ましいという考え方が基になっている。
- 逆にフレームワークの機能(Facade等)を利用したUnitテストを書きたい場合は、継承元をTests/TestCaseに変更する。
- テストファイル作成
# php artisan make:test --unit Models/ClientTest
- TDDの考え方
- レッドフェーズ
- テストが失敗するフェーズ。テストコードから先に書き、後からプロダクションコードを書くので必ず失敗する。
- グリーンフェーズ
- 最短でテストが通る実装を書く。
- リファクタリングフェーズ
- 成功したコードを正しく綺麗にリファクタリングする。
コントローラーテスト
テストクラス作成コマンド
# php artisan make:test Http/Controllers/ClientControllerTest
実行後ファイル
<?php
namespace Tests\\Feature\\Http\\Controller;
use Illuminate\\Foundation\\Testing\\RefreshDatabase;
use Illuminate\\Foundation\\Testing\\WithFaker;
use Tests\\TestCase;
class ClientControllerTest extends TestCase
{
/**
* A basic feature test example.
*
* @return void
*/
public function test_example()
{
$response = $this->get('/');
$response->assertStatus(200);
//下記のコードでも同様の意味
//$response->assertStatus(Response::HTTP_OK);
}
}
テストがあると良いケース
- 複雑な計算がある
- 複雑な条件がある
- 多数のパターンがある