データベースおよびその他の一般的なインフラストラクチャ関連のテスト用の PHP の統合テスト ライブラリ。
これは、さまざまなイベントにフックしてフィクスチャを実行する PHPUnit の拡張機能のセットとして開発されています。
現在、次の PHPUnit フックでカスタム フィクスチャを実行できます。
最初のテスト前
テスト前
アフターテスト
最終テスト後
WIP: WithBeforeTestFixtureName および WithAfterTestFixtureName を使用した AMQP 固有のテスト フィクスチャ
PHPUユニット
作曲家経由
composer require --dev hrodic/php-integration-testing
PHPUnit 構成 XML ファイルでは、その構成で拡張子を指定する必要があります。
使用する構成ファイル名を指定できます。デフォルトは .integration-testing.json
<extensions> <extension class="IntegrationTestingPHPUnitRunnerExtensionHandler"> <arguments> <string>.integration-testing.json</string> </arguments> </extension> </extensions>
phpunit-integration.xml.dist の例も確認してください。
PHPUnit 拡張機能についてサポートが必要な場合は、公式ドキュメントを参照してください。
MySQL または MariaDB の統合をテストする必要がある場合は、PDO ドライバー拡張機能を使用します。
json 構成ファイル内にある構成パラメーターが必要です。
最も重要なパラメータは、DSN、データベースのユーザー名とパスワード、およびいくつかのフィクスチャ パス定義です。
例:
"pdo": { "dsn": "mysql:host=localhost:3306;dbname=test;charset=utf8", "user": "test", "password": "test", "fixtures": { "beforeFirstTest": { "path": "tests/fixtures/before-first-test", "extension": "sql" }, "beforeTest": { "path": "tests/fixtures/before-test", "extension": "sql" }, "afterTest": { "path": "tests/fixtures/after-test" }, "afterLastTest": { "path": "tests/fixtures/after-last-test" } } },
AMQP (RabbitMQ でテスト済み) フィクスチャと操作を試すこともできます。
構成ファイルを使用して、接続とフック操作を構成します。
注:
フック定義はオプションなので、必要なものだけを設定してください。
メッセージを発行できるのは、 beforeFirstTest
とbeforeTest
のみです。
4 つのフックすべてでキューをパージできます。
パブリッシュするメッセージ本文のファイル拡張子はデフォルトでjson
になります
交換をdirect
として設定している場合は、 routing_key
を使用します。 fanout
の場合は空の文字列として定義できます
"amqp": { "host": "localhost", "port": 5672, "user": "test", "password": "test", "vhost": "/", "fixtures": { "beforeFirstTest": { "purgeQueues": [ "before-first-test-queue" ], "publishMessages": [ { "exchange": "test-exchange", "queue": "before-first-test-queue", "routing_key": "before-first-test", "path": "tests/fixtures/before-first-test", "extension": "json" } ] }, "beforeTest": { "purgeQueues": [ "before-test-queue" ], "publishMessages": [ { "exchange": "test-exchange", "queue": "before-test-queue", "routing_key": "before-test", "path": "tests/fixtures/before-test" } ] }, "afterTest": { "purgeQueues": [ "before-test-queue" ] }, "afterLastTest": { "purgeQueues": [] } } }
PDO フィクスチャは単なる SQL ファイルです。
特定のフック カテゴリにあるすべてのフィクスチャは、トランザクション内で順番に実行されます。
各段階で SQL を作成する方法とデータベースの整合性はユーザー次第です。このライブラリは、最初にフィクスチャをセットアップし、各テスト後に混乱を解消するのが一般的ですが、いかなる規則に従うことも強制しません。
作成、挿入、削除など、ユーザーが行うように設定したあらゆる操作を行うことができます。テスト データベースは実際のデータベースから分離する必要があることに注意してください。
4 つのフィクスチャ フック タイプはすべて、好みのディレクトリに配置できます。
すべての特定のテストで発生する BeforeTest フックと AfterTest フックについては、WithBeforeTestFixtureName インターフェイスや WithAfterTestFixtureName インターフェイスを実装することで、汎用の Before フィクスチャと AfterTest フィクスチャの直後に実行される特定のフィクスチャを提供することもできます。
final class YourIntegrationTest extends TestCase implements WithBeforeTestFixtureName, WithAfterTestFixtureName { private const FIXTURE_NAME = 'pdo-integration-test'; public static function getAfterTestFixtureName(): string { return self::FIXTURE_NAME; } public static function getBeforeTestFixtureName(): string { return self::FIXTURE_NAME; } public function testYourRepositoryHere(): void { // arrange // act // assert against real database (your fixtures are already there!) } }
拡張機能はメソッドが定義されているかどうかを確認し、それらのメソッドを使用してメインの BEFORE_TEST_PDO_FIXTURES_PATH および AFTER_TEST_PDO_FIXTURES_PATH ディレクトリ内のサブディレクトリを見つけます。
テスト/フィクスチャ フォルダを見ると、フィクスチャを整理する方法の例が表示されます。複数の SQL ファイルを持つことができ、拡張機能はそれらを順番に読み取って実行します。
├── after-last-test # AFTER_LAST_TEST_PDO_FIXTURES_PATH, executed once, at the end │ └── 01.sql ├── after-test # AFTER_TEST_PDO_FIXTURES_PATH, executed after each test │ ├── 01.sql │ └── pdo-integration-test # executed after each test inside the class that defines this fixture name │ └── 01.sql ├── before-first-test # BEFORE_FIRST_TEST_PDO_FIXTURES_PATH, executed once, at the beginning │ └── 01.sql └── before-test # BEFORE_TEST_PDO_FIXTURES_PATH, executed before each test ├── 01.sql └── pdo-integration-test # executed before each test inside the class that defines this fixture name └── 01.sql
統合テストには、いくつかのインフラストラクチャを導入する必要があります。
このライブラリは、アクセス可能なデータベースまたはその他のインフラストラクチャがすでに配置されており、データベースが作成されていることを前提としています (docker-compose.yml ファイルを確認してインスピレーションを得ることができます)。