この記事の目的は、テストに精通していない人々に、最小限の水とロシア語ですべてを1か所で収集して、本当に迅速にテストを開始する方法を示すことです。 非常に原始的なものにしてください。 すでにTDD、SOLID、およびその他の原則に従って生活している人にとっては、あまり面白くないかもしれません。 しかし、最後まで読んだ後、誰でもテストの世界に自信を持って最初の一歩を踏み出すことができます。
受け入れ、機能、単体テストまたは単体テストを検討します。
また、この記事は、実際には「Codeception」というタイトルの多くの記事が1つの受理テストにすぎないという事実によって促されました。
PS:私はプロではなく、すべてを間違える可能性があることをすぐに警告します。
ComposerとCodeceptionのインストール
フレーズに困惑している場合
$ composer require "codeception/codeception:*" $ alias cept="./vendor/bin/codecept"
開始するには、優れたComposerツールが必要です。 ほとんどのプロジェクトでは、すでにインストールされています。 しかし、それをインストールすることも問題ではありません。 すべてのオプションは公式ページにリストされています: https ://getcomposer.org/download/最も一般的で簡単な方法は、ページをスクロールダウンして、* .pharファイルをプロジェクトのルートにダウンロードすることです。
ベストプラクティスは、そうすることが悪いことを教えてくれます。 / etc / binに配置し、実行権を与え、名前をcomposerに変更する必要があります。 記事を最後まで読んだら、彼らの話を聞いてください。
Composerを構成する2番目のステップ、および非常によくある回答、Composerが破損した場合の対処方法:FXPプラグインを更新/インストールします。 https://packagist.org/packages/fxp/composer-asset-pluginで「存続」します。多くの場合、次のコマンドでインストールされます 。
$ php composer.phar global require "fxp/composer-asset-plugin:~1.4.2"
この記事を読むときにサイトに表示されるバージョンを入力する必要があることに注意してください。
作業を開始する前の最終セットアップは、Composerを使用してCodeceptionを設定することです。
$ php composer.phar require "codeception/codeception:*"
その後、Codeceptionの実行可能ファイルは、Linuxの場合は./vendor/bin/codeceptサブディレクトリに、Windowsの場合は./vendor/bin/codecept.batにあります。 長い間、各起動の前にこれを入力してください。 したがって、削減を行います。
Linuxの場合: $ alias cept="./vendor/bin/codecept"
Windowsの場合、プロジェクトのルート(テストの実行元)で、新しいbatファイルを作成します:cept.bat
@echo off @setlocal set CODECEPT_PATH=vendor/bin/ "%CODECEPT_PATH%codecept.bat" %* @endlocal
その後、コンソールのceptコマンドはCodeceptionによってヘルプページを返します。 また、任意のディレクトリからcept.batを実行する場合は、PATHディレクティブに注目してください。
このテーマに関するいくつかのヒント:
コンポーザーからパッケージを削除する: $ php composer.phar remove codeception/codeception
問題が発生した場合: "Fatal error: Allowed memory size of 12345678 bytes exhausted"
Composerは、わずかに変更された呼び出しが書き込まれるリンクをすぐに表示します。 $ php -d memory_limit=-1 composer.phar {_}
最初のテストを作成します: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
-
tests/_bootstrap.php
、次の定数を追加しtests/_bootstrap.php
:defined('YII_ENV') or define('YII_ENV', 'test');
。 ファイルがない場合は、ルートcodeception.yml
settings.bootstrapを作成して追加します:_bootstrap.php。 そのようなファイルは、テストですべてのフォルダーに入れる必要があります。 忘れると、Codeceptionがこれを思い出させます。 - yiiアプリケーションのconfigフォルダーで、
main.php
横にtest.php
入れtest.php
。これはマニュアルから記入します - 専門的な方法で、モジュールがベンダーを認識せず、ファイルシステム内の場所を理解するのに問題があることを発見しました。 そのため、
test.php
を追加して、さらに2、3行追加しました。
require_once(__DIR__ . '/../../../vendor/autoload.php'); require_once(__DIR__ . '/../../../vendor/yiisoft/yii2/Yii.php'); require_once(__DIR__ . '/../../../common/config/bootstrap.php'); // @approot - . + $_SERVER['SCRIPT_FILENAME'] = realpath(Yii::getAlias('@approot/web/index.php')); $_SERVER['SCRIPT_NAME'] = '/'.basename($_SERVER['SCRIPT_FILENAME']);
$ 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つの記事ではないことを理解しています。 同じベストプラクティスは言うまでもなく、それらは独自のコーンでいっぱいになるか、事前に読むことができます。
それでは、この形式で始めて、何が起こるか見てみましょう。
目的の聴衆が見つかった場合、モックオブジェクト、フィクスチャ、ダンプを使用したテストデータベース、およびこの方向で使用されるより多くの興味深いことについて間違いなく話します。