ダミーのCodeceptionを使用したテスト：3種類のテスト

この記事の目的は、テストに精通していない人々に、最小限の水とロシア語ですべてを1か所で収集して、本当に迅速にテストを開始する方法を示すことです。 非常に原始的なものにしてください。 すでにTDD、SOLID、およびその他の原則に従って生活している人にとっては、あまり面白くないかもしれません。 しかし、最後まで読んだ後、誰でもテストの世界に自信を持って最初の一歩を踏み出すことができます。

受け入れ、機能、単体テストまたは単体テストを検討します。

また、この記事は、実際には「Codeception」というタイトルの多くの記事が1つの受理テストにすぎないという事実によって促されました。
PS：私はプロではなく、すべてを間違える可能性があることをすぐに警告します。

ComposerとCodeceptionのインストール

フレーズに困惑している場合

$ composer require "codeception/codeception:*" $ alias cept="./vendor/bin/codecept" 

 @echo off @setlocal set CODECEPT_PATH=vendor/bin/ "%CODECEPT_PATH%codecept.bat" %* @endlocal 

最初のテストを作成します：AcceptanceまたはAcceptance

これで、最初のテストから一歩離れました。 私たちのサイトがメインページとAboutページを開くことを確認します。 正しい応答コード「200」を返し、キーワードが含まれていること。

実際-これは受け入れテストの本質です。プログラミングから遠く離れた人がアクセスできるものをチェックすること：ページのコンテンツを表示する、ログインを試みるなど。

$ cept bootstrap最初のインストール後、1回限りの初期化を行います
$ cept generate:cept acceptance SmokeTest最初のテストケースを作成します

テスト/受け入れ/ SmokeTestCept.phpを開き、新しいAcceptanceTesterとwantoを2行に追加します 。 出力では、以下を取得する必要があります。

 $I = new AcceptanceTester($scenario); $I->wantTo('Check that MainPage and About are work'); $I->amOnPage('/'); $I->seeResponseCodeIs(\Codeception\Util\HttpCode::OK); $I->see(' '); // !       $I->amOnPage('/about'); $I->seeResponseCodeIs(\Codeception\Util\HttpCode::OK); $I->see(' '); // !       about 

ご存知のとおり：早期に起動します。 テストが失敗したことを示すメッセージが表示されます。 なぜなら 彼は、メインページを開くサイトを完全に認識していません。 tests/acceptance.suite.ymlファイルのmodules.config.PhpBrowser.urlセクションを編集します。 たとえば、私はそこに着きました： url: http://rh.dev/

また、テストコードでは、ダビングがすぐに目を引きます。 tests/_support/AcceptanceTester.phpクラスに新しいメソッドを追加することでリファクタリングできます。 または、それを継承して、独自に作成し、そこにメソッドを追加します。 しかし、これはテストに関する別の会話ではありません。

そのため、次のコマンドをクリックします。

$ cept build再構築には常に再構築が必要です
$ cept run acceptance実行テストを実行します

次のメッセージが表示されます： OK（1テスト、4アサーション）

実際に-それだけです！ 最初のテストを作成しました。これにより、サイト全体のページの妥当性を確認できます。 これらは、これらのページが多数あり、ボスが毎回より速く回転したい場合に特に便利です。 サイトで何かが壊れたことをscるのを忘れないでください。

将来的には、フォーム、ajax、REST、SeleniumなどのJavaScriptをチェックすることもできます。

最初のテストの作成：機能的または機能的

すぐにドキュメントからの重要な引用：「フレームワークを使用しない場合、機能テストを書くことは実質的に意味がありません。」
この種のテストには、サポートされているCodeceptionのフレームワークが必要です：Yii1 / 2、ZF、Symfonyなど。 これは機能テストにのみ適用されます。
残念ながら、サポートされているもののリストを含む特定のリンクを見つけることができませんでした。

機能テストは、受け入れテストに少し似ています。 ただし、後者とは異なり、Webサーバーを起動する必要はありません。リクエスト変数のエミュレーション（get、post）を使用してフレームワークを呼び出します。
公式ドキュメントでは、機能テストを使用してアプリケーションの不安定部分をテストし、受け入れテストを使用して安定部分をテストすることを推奨しています。 これは、機能テストではWebサーバーを使用する必要がないため、より詳細なデバッグ出力を提供できる場合があるためです。

まず最初に行う必要があるのは、 tests/functional.suite.yml設定ファイルを編集し、「＃add a framework module here」というフレーズではなく、フレームワークのモジュールを示すことです。 そして、設定のすべての微妙な点-公式ドキュメントを読む必要があります。

非テンプレートYii2の例を示します（BasicまたはAdvancedテンプレートをインストールしている場合、このページの上部にそのようなオプションの説明があります）： http : //codeception.com/for/yii#Manual-Setup--Configuration

$ cept generate:cept functional myFirstFunctional最初のテストスクリプトを作成します
作成されたテストtests/functional/myFirstFunctionalCept.php 、以前のテストファイルと同様に記入されます。 最初の行に1つだけ違いがあります：
$I = new FunctionalTester($scenario);

さらに、上記の資料について：

$ cept build再構築には常に再構築が必要です
$ cept run functional実行テストを実行します

次のメッセージが表示されます： OK（1テスト、4アサーション）

最初のテストの作成：単体テストまたは単体テット

前のテストでアプリケーション全体を見た場合：エントリポイントから出口ポイントまで。 それはユニットテストです-それらはすべてを棚に置き、すべてのブリック、別名モジュール、アプリケーションをテストすることを可能にします。

テストする内容と深さ-ハブには多くの記事があります 場合によっては、すべてのメソッドとクラスを完全にテストすることが必須であることを教えてくれます。 他では、会話はわずかに異なります。 たとえば、この記事は私の目を引きました： 100パーセントのコードカバレッジの悲劇

ActiveRecordパターンに従って動作するクラスをテストします。配列からデータを読み込み、検証を実行します。 その後、必須フィールドが追加され、どこでも通常のように、誰もがそれを忘れます。テストはすぐに異議を表明します。

第2段階では、ヘルパーの1人をテストします。 このアイデアは有用というよりも示唆的なものです。

始まりはすでにおなじみです：

tests/unit.suite.ymlフレームワークに応じて編集します（使用する場合）。
$ cept build構成ファイルに変更を加えた後、常に再構築が必要です。
$ cept generate:test unit SmokeUnit将来のテスト用にダミーを作成します。

 <?php namespace tests\unit; use common\helpers\JsonRhHelper; use frontend\modules\wot\models\WotMonitoringClan; class SmokeUnitTest extends \Codeception\Test\Unit { /** * @var \UnitTester */ protected $tester; /** * @var array -       */ protected $clanFixture = [ 'WotMonitoringClan' => [ 'clan_id' => 1, 'status' => '1', 'name' => 'DNO', 'tag' => ' ' ] ]; protected function _before() { } protected function _after() { } /** * ,       */ public function testCheckClanAR() { $clan = new WotMonitoringClan(); $clan->load($this->clanFixture); // -     $this->assertTrue($clan->validate()); //    $fullClanTag = '[' . $clan->tag . ']'; $this->assertTrue($clan->fullClanTag === $fullClanTag); // ,   ,   $clan->clan_id = null; $this->assertFalse($clan->validate()); } /** * ,   JSONa      */ public function testStaticHelper() { //   $expectedArray = ['success' => 'myTest']; $respArray = JsonRhHelper::success('myTest', false); $this->assertTrue($expectedArray === $respArray); //    $expectedArray = [ 'error' => [ 'message' => 'myTest', 'id' => 13255 ] ]; $respArray = JsonRhHelper::error('myTest', 13255, false); $this->assertTrue($expectedArray === $respArray); } } 

$ cept run unit実行テストを実行します。 OK（2つのテスト、5つのアサーション）を参照してください

私は少し説明します：
$this->assertTrue($clan->validate()); -名前が示すように、変数またはメソッドの結果に論理的なTRUEが期待されます。 カウンターウェイト： $this->assertFalse()
$this->assertEquals(1, count($myArray)); -2つのパラメーターが等しいことを期待する

つまり いくつかのチェックで基本的なことができます。 いわば、自分でストローを置いてください。 余暇には、チェックの残りの表現について読んでください ： http : //www.phpunit.de/manual/3.4/en/api.html#api.assert

ところで！ これですべてのテストが作成され、アプリケーションは新しい方法で動作を開始する準備ができました。 ロールアウトする前にテストが既に1回実行される場合。 最初に言及しなかったことをお伝えします。 runパラメーターの後に、テストの種類を省略できます。 その後、すべてのタイプのテストが順番に実行されます： $ cept run

結論として

もちろん、この記事ではすべてが単純化され、表面的に書かれています。 しかし、あなた自身は、このトピックが1つの記事ではないことを理解しています。 同じベストプラクティスは言うまでもなく、それらは独自のコーンでいっぱいになるか、事前に読むことができます。

それでは、この形式で始めて、何が起こるか見てみましょう。

目的の聴衆が見つかった場合、モックオブジェクト、フィクスチャ、ダンプを使用したテストデータベース、およびこの方向で使用されるより多くの興味深いことについて間違いなく話します。