Biblioteca de pruebas de integración en PHP para bases de datos y otras pruebas comunes relacionadas con la infraestructura.
Está desarrollado como un conjunto de extensiones para PHPUnit que se conecta a diferentes eventos y ejecuta sus accesorios.
Actualmente puedes ejecutar dispositivos personalizados en los siguientes enlaces PHPUnit:
Antes de la primera prueba
Antes de la prueba
Después de la prueba
Después de la última prueba
WIP: dispositivos de prueba específicos de AMQP con WithBeforeTestFixtureName y WithAfterTestFixtureName
Unidad PHP
Vía compositor
composer require --dev hrodic/php-integration-testing
En el archivo XML de configuración de PHPUnit debe especificar la extensión con su configuración.
Puede especificar el nombre del archivo de configuración que utilizará. El valor predeterminado es .integration-testing.json
<extensions> <extension class="IntegrationTestingPHPUnitRunnerExtensionHandler"> <arguments> <string>.integration-testing.json</string> </arguments> </extension> </extensions>
También puedes consultar el ejemplo phpunit-integration.xml.dist
Si necesita ayuda con las extensiones PHPUnit, consulte la documentación oficial
Si necesita probar la integración de MySQL o MariaDB, utilice la extensión del controlador PDO.
Requiere parámetros de configuración que se pueden encontrar en el archivo de configuración json.
Los parámetros más importantes son DSN, nombre de usuario y contraseña de su base de datos + algunas definiciones de ruta de dispositivo.
Ejemplo:
"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" } } },
También puede probar los dispositivos y operaciones de AMQP (probado en RabbitMQ).
Configure su conectividad y las operaciones de enlace utilizando el archivo de configuración.
Notas:
Las definiciones de ganchos son opcionales, así que simplemente configure las que necesite.
Solo puedes publicar mensajes en beforeFirstTest
y beforeTest
.
Puede purgar colas en los cuatro ganchos.
extensión de archivo de los cuerpos de los mensajes para publicar los valores predeterminados en json
use routing_key
si tiene su intercambio configurado como direct
. Puedes definirlo como una cadena vacía si 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 dispositivo PDO es solo un archivo SQL.
Todos los dispositivos ubicados en una categoría de gancho específica se ejecutarán en orden y dentro de una transacción.
La forma de crear el SQL y la integridad de la base de datos en cada etapa depende de usted. La biblioteca no te obliga a seguir ninguna convención, aunque es común configurar los accesorios al principio y limpiar el desorden después de cada prueba.
Puede crear, insertar, eliminar o cualquier cosa que configure para hacer su usuario. Recuerde, su base de datos de prueba debe estar aislada de cualquier base de datos real.
Los cuatro tipos de ganchos para dispositivos se pueden colocar en el directorio que prefiera.
Para los enlaces BeforeTest y AfterTest, que ocurren en cada prueba específica, también puede proporcionar dispositivos específicos que se ejecutarán justo después de los dispositivos genéricos Antes y Después implementando las interfaces WithBeforeTestFixtureName y/o 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!) } }
La extensión comprobará si los métodos están definidos y los utilizará para localizar subdirectorios dentro de los directorios principales BEFORE_TEST_PDO_FIXTURES_PATH y AFTER_TEST_PDO_FIXTURES_PATH.
Si echas un vistazo a la carpeta pruebas/dispositivos, verás un ejemplo de cómo puedes organizar tus dispositivos. Puede tener varios archivos SQL y la extensión los leerá y ejecutará en orden.
├── 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
Las pruebas de integración requieren que exista cierta infraestructura.
Esta biblioteca supone (puede consultar el archivo docker-compose.yml para inspirarse) que ya tiene una base de datos accesible u otra infraestructura instalada y que la base de datos está creada.