doctrine test bundle

Qu'est-ce que ça fait ?

Cet ensemble fournit des fonctionnalités qui vous aident à exécuter plus efficacement la suite de tests de votre application basée sur le framework Symfony avec des tests isolés.

Il fournit un StaticDriver qui encapsulera votre classe Driver initialement configurée (comme DBALDriverPDOMysqlDriver ) et conservera une connexion à la base de données de manière statique dans le processus php actuel.

Avec l'aide d'une classe d'extension PHPUnit, il commencera une transaction avant chaque cas de test et l'annulera une fois le test terminé pour toutes les connexions DBAL configurées. Cela entraîne une amélioration des performances car il n'est pas nécessaire de reconstruire le schéma, d'importer un dump SQL de sauvegarde ou de réinsérer les appareils avant chaque scénario de test. Tant que vous évitez d'émettre des requêtes DDL qui pourraient entraîner des validations de transactions implicites (comme ALTER TABLE , DROP TABLE etc ; voir https://wiki.postgresql.org/wiki/Transactional_DDL_in_PostgreSQL:_A_Competitive_Analysis), vos tests seront isolés et tous verront le même état de base de données.

Il comprend également un Psr6StaticArrayCache qui sera automatiquement configuré comme cache de métadonnées et de requêtes pour tous les EntityManagers. Cela a considérablement amélioré la vitesse et l'utilisation de la mémoire de mes suites de tests ! Ceci est particulièrement utile si vous disposez de nombreux tests qui démarrent des noyaux (comme les tests Controller ou les tests ContainerAware) et utilisent des entités Doctrine.

Comment installer et utiliser ce Bundle ?

1. installer via composer

 composer require --dev dama/doctrine-test-bundle

2. Si vous n'utilisez pas Flex, activez le bundle en ajoutant la classe à bundles.php

 <?php// config/bundles.phpreturn [//...DAMADoctrineTestBundleDAMADoctrineTestBundle::class => ['test' => true],//...];

3. À partir de la version 8 et uniquement lorsque vous utilisez DBAL <4, vous devez vous assurer que use_savepoints sont activés sur votre configuration DBAL de doctrine pour toutes les connexions pertinentes :

 doctrine : dbal : connexions : par défaut : use_savepoints : vrai

Utiliser le bundle avec PHPUnit

1. Ajoutez l'extension à votre configuration XML PHPUnit

• PHPUnit 8 ou 9 :

   <unitéphp>
      ...
      <extensions>
          <extension class="DAMADoctrineTestBundlePHPUnitPHPUnitExtension" />
      </extensions>
  </phpunité>

• PHPUnit 10+ :

   <unitéphp>
      ...
      <extensions>
          <bootstrap class="DAMADoctrineTestBundlePHPUnitPHPUnitExtension" />
      </extensions>
  </phpunité>

2. Assurez-vous d'avoir également phpunit/phpunit disponible en tant que dépendance dev ( les versions 8, 9 et 10 sont prises en charge avec l'extension intégrée ) pour exécuter vos tests. Alternativement, ce bundle est également compatible avec symfony/phpunit-bridge et son script simple-phpunit . (Remarque : vous devrez peut-être vous assurer que le pont phpunit nécessite la bonne version de PHPUnit 8+ en utilisant la variable d'environnement SYMFONY_PHPUNIT_VERSION ).

3. C'est ça! À partir de maintenant, toutes les modifications que vous apportez à la base de données dans chaque cas de test (qu'il s'agisse d'un WebTestCase , d'un KernelTestCase ou de tout autre test personnalisé) sont automatiquement annulées pour vous.

Utiliser le bundle avec Behat

Activez l'extension dans votre configuration Behat (par exemple behat.yml )

 défaut:   # ...
   extensions : DAMADoctrineTestBundleBehatServiceContainerDoctrineExtension : ~

C'est ça! À partir de maintenant, toutes les modifications que vous apportez à la base de données dans chaque scénario sont automatiquement annulées pour vous.

Veuillez noter que cela ne fonctionne que si les tests sont exécutés dans le même processus que Behat. Cela signifie que cela ne peut pas fonctionner lorsque vous utilisez par exemple Selenium pour appeler votre application.

Configuration

Le bundle expose une configuration qui ressemble à ceci par défaut :

 dama_doctrine_test:enable_static_connection : trueenable_static_meta_data_cache : trueenable_static_query_cache : true

Le paramètre enable_static_connection: true signifie qu'il l'activera pour toutes les connexions dbal de doctrine configurées.

Vous pouvez l'activer de manière sélective uniquement pour certaines connexions si nécessaire :

 dama_doctrine_test:enable_static_connection:connection_a : vrai

Contrôler la façon dont les connexions sont conservées de manière statique dans le processus php actuel

Par défaut, chaque connexion DBAL de doctrine configurée aura sa propre connexion de pilote qui est gérée dans le processus php actuel. Si vous devez personnaliser ce comportement, vous pouvez choisir différentes « clés de connexion » utilisées pour sélectionner les connexions du pilote.

Exemple pour 2 connexions qui réutiliseront la même instance de connexion de pilote :

 doctrine:dbal:connections:default:url: '%database.url1%'foo:url: '%database.url2%'dama_doctrine_test:connection_keys:# l'attribution de la même clé entraînera la réutilisation de la même connexion de pilote interne pour les deux connexions DBAL par défaut : custom_keyfoo : custom_key

Depuis la version 8.1.0 : pour les connexions avec des répliques en lecture/écriture, le bundle utilisera par défaut la même connexion de pilote sous-jacente pour le principal et également pour les répliques. Cela résout un problème où des incohérences se produisaient lors de la lecture/écriture sur différentes connexions. Cela peut également être personnalisé comme suit :

 doctrine:dbal:connections:default:url: '%database.url%'replicas:replica_one:url: '%database.url_replica%'dama_doctrine_test:connection_keys:# l'attribution de clés différentes entraînera l'utilisation de connexions de pilote internes distinctes pour les clés principales et réplicadefault : primaire : custom_key_primaryreplicas : replica_one : custom_key_replica

Exemple

Un exemple d'utilisation peut être vu dans les tests fonctionnels inclus dans ce bundle : https://github.com/dmaicher/doctrine-test-bundle/tree/master/tests

• l'amorçage initial de la base de données est effectué à l'aide du fichier d'amorçage PHPUnit : https://github.com/dmaicher/doctrine-test-bundle/blob/master/tests/bootstrap.php

• plusieurs tests qui garantissent que toutes les modifications des tests précédents sont annulées : https://github.com/dmaicher/doctrine-test-bundle/blob/master/tests/Functional/PhpunitTest.php

Ce bundle est également utilisé sur la suite de tests officielle Symfony Demo : https://github.com/symfony/demo

Débogage

Parfois, il peut être utile de pouvoir déboguer le contenu de la base de données lorsqu'un test échoue. Comme normalement, toutes les modifications sont annulées automatiquement, vous pouvez le faire manuellement :

 fonction publique testMyTestCaseThatINeedToDebug()
{// ... quelque chose qui change l'état de la base de donnéesDAMADoctrineTestBundleDoctrineDBALStaticDriver::commit();
    die;// maintenant les modifications de la base de données sont réellement conservées et vous pouvez les déboguer}

Dépannage

Dans le cas où vous exécutez (peut-être sans le savoir) des requêtes lors de vos tests qui valident implicitement une transaction ouverte (voir https://dev.mysql.com/doc/refman/8.0/en/implicit-commit.html par exemple) vous pourriez voir une erreur comme celle-ci :

DoctrineDBALDriverPDOException: SQLSTATE[42000]: Syntax error or access violation: 1305 SAVEPOINT DOCTRINE2_SAVEPOINT_2 does not exist

Actuellement, il n'existe aucun moyen pour cet ensemble de fonctionner avec ces requêtes, car elles ne peuvent tout simplement pas être annulées une fois le scénario de test terminé.

Voir aussi #58