Bibliothèque de tests d'intégration en PHP pour les bases de données et autres tests courants liés à l'infrastructure.
Il est développé comme un ensemble d'extensions pour PHPUnit qui s'accroche à différents événements et exécute vos appareils.
Actuellement, vous pouvez exécuter des appareils personnalisés sur les hooks PHPUnit suivants :
AvantPremierTest
Avant le test
AprèsTest
Après le dernier test
WIP : montages de test spécifiques à AMQP avec WithBeforeTestFixtureName et WithAfterTestFixtureName
PHPUnit
Via le compositeur
composer require --dev hrodic/php-integration-testing
Sur le fichier XML de configuration PHPUnit, vous devez spécifier l'extension avec sa configuration.
Vous pouvez spécifier le nom du fichier de configuration que vous utiliserez. La valeur par défaut est .integration-testing.json
<extensions> <extension class="IntegrationTestingPHPUnitRunnerExtensionHandler"> <arguments> <string>.integration-testing.json</string> </arguments> </extension> </extensions>
Vous consultez également l'exemple phpunit-integration.xml.dist
Si vous avez besoin d'aide avec les extensions PHPUnit, veuillez vous référer à la documentation officielle
Si vous devez tester l'intégration de MySQL ou MariaDB, utilisez l'extension du pilote PDO.
Cela nécessite des paramètres de configuration qui se trouvent dans le fichier de configuration json.
Les paramètres les plus importants sont le DSN, le nom d'utilisateur et le mot de passe de votre base de données + quelques définitions de chemin d'appareil.
Exemple:
"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" } } },
Vous pouvez également essayer les appareils et opérations AMQP (testés sur RabbitMQ).
Configurez votre connectivité et les opérations de hook à l'aide du fichier de configuration.
Remarques :
Les définitions de hook sont facultatives, il vous suffit donc de configurer celles dont vous avez besoin.
Vous ne pouvez publier des messages que sur beforeFirstTest
et sur beforeTest
.
Vous pouvez purger les files d’attente dans les quatre hooks.
extension de fichier des corps de message pour publier les valeurs par défaut en json
utilisez routing_key
si votre échange est configuré comme direct
. Vous pouvez le définir comme une chaîne vide en cas de 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": [] } } }
Un appareil PDO n'est qu'un fichier SQL.
Tous les appareils situés dans une catégorie de crochet spécifique seront exécutés dans l'ordre et au sein d'une transaction.
La façon dont vous créez le SQL et l’intégrité de la base de données à chaque étape dépend de vous. La bibliothèque ne vous oblige à suivre aucune convention, bien qu'il soit courant de configurer les appareils au début et de nettoyer vos dégâts après chaque test.
Vous pouvez créer, insérer, supprimer ou tout ce que vous configurez pour que votre utilisateur fasse. N'oubliez pas que votre base de données de tests doit être isolée de toute base de données réelle !
Les quatre types de crochets de luminaire peuvent être placés dans le répertoire de votre choix.
Pour les hooks BeforeTest et AfterTest, qui se produisent dans chaque test spécifique, vous pouvez également fournir des appareils spécifiques à exécuter juste après les appareils génériques Avant et Après en implémentant les interfaces WithBeforeTestFixtureName et/ou WithAfterTestFixtureName.
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!) } }
L'extension vérifiera si les méthodes sont définies et les utilisera pour localiser les sous-répertoires dans les répertoires principaux BEFORE_TEST_PDO_FIXTURES_PATH et AFTER_TEST_PDO_FIXTURES_PATH.
Si vous jetez un œil au dossier tests/fixtures, vous verrez un exemple sur la façon dont vous pouvez organiser vos luminaires. Vous pouvez avoir plusieurs fichiers SQL et l’extension les lira et les exécutera dans l’ordre.
├── 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
Les tests d’intégration nécessitent la mise en place d’une certaine infrastructure.
Cette bibliothèque suppose (vous pouvez consulter le fichier docker-compose.yml pour vous inspirer) que vous disposez d'une base de données accessible ou d'une autre infrastructure déjà en place et que la base de données est créée.