Home >Backend Development >PHP Tutorial >Quick Tip: Testing Symfony Apps with a Disposable Database
Key Points
app/config/config_test.php
. Support for in-memory databases using SQLite3 can facilitate testing by sending SQL queries to functional databases, eliminating the need to mock the repository classes. Testing code that interacts with a database can be very painful. Some developers mock database abstractions, so there is no actual query to test. Other developers create test databases for development environments, but this can also be painful in terms of continuous integration and maintaining the state of this database. In-memory database is an alternative to these options. Since they are only present in the application's memory, they are truly one-time and very suitable for testing. Thankfully, these are very easy to set up with Symfony applications that use Doctrine. Try reading our guide on functional testing with Symfony to understand the end-to-end behavior of testing applications.
Symfony environment configuration
One of the most powerful features of the Symfony framework is the ability to create different environments with their own unique configurations. Symfony developers may ignore this feature, especially the lesser-known aspects of testing environments studied here. Symfony's guide on mastering and creating new environments explains how frameworks handle configurations of different environments and shows some useful examples. The configuration file that needs to be edited to set the discardable test database is app/config/config_test.php
. When accessing an application in a test suite, the kernel will load using the test environment and this configuration file will be processed.
In-memory database using Doctrine
SQLite3 supports in-memory databases and is very suitable for testing. With these databases, you can test your application by actually sending SQL queries to the functional database, thus eliminating the effortless simulation of repository classes with predefined behavior. The database will be new at the start of the test and will be cleanly destroyed at the end. To override the default Doctrine connection configuration, you need to add the following line to the test environment configuration file. If you have multiple Doctrine connections configured in your application, you may need to adjust it a little to match.
<code class="language-yaml"># app/config/config_test.yml doctrine: dbal: driver: pdo_sqlite memory: true charset: UTF8</code>
Using database in test classes
When using this shiny new in-memory database in the test class, the schema must be built first. This means creating a table of entities and loading any fixtures required for the test suite. The following class can be used as a database bootstrap, which does most of the work. It has the same effect as forcing the Doctrine mode update console command to run.
<code class="language-php"><?php namespace Tests\AppBundle; use Doctrine\ORM\EntityManager; use Doctrine\ORM\Tools\SchemaTool; use Symfony\Component\HttpKernel\KernelInterface; class DatabasePrimer { public static function prime(KernelInterface $kernel) { // 确保我们处于测试环境中 if ('test' !== $kernel->getEnvironment()) { throw new \LogicException('Primer must be executed in the test environment'); } // 从服务容器获取实体管理器 $entityManager = $kernel->getContainer()->get('doctrine.orm.entity_manager'); // 使用我们的实体元数据运行模式更新工具 $metadatas = $entityManager->getMetadataFactory()->getAllMetadata(); $schemaTool = new SchemaTool($entityManager); $schemaTool->updateSchema($metadatas); // 如果您使用的是 Doctrine Fixtures Bundle,您可以在此处加载它们 } }</code>
If you need an entity manager to test the class, you must apply the bootloader:
<code class="language-php"><?php namespace Tests\AppBundle; use Symfony\Bundle\FrameworkBundle\Test\KernelTestCase; use Tests\AppBundle\DatabasePrimer; class FooTest extends KernelTestCase { public function setUp() { self::bootKernel(); DatabasePrimer::prime(self::$kernel); } public function testFoo() { $fooService = self::$kernel->getContainer()->get('app.foo_service'); // ... } }</code>
In the example above, the container is used to get the service being tested. If this service depends on the entity manager, it will be built using the same entity manager booted in the setUp
method. If more control is needed, such as mocking another dependency, you can always retrieve the entity manager from the container and use it for manual instantiation of the class that needs to be tested. Using Doctrine Fixtures Bundle to populate a database with test data may also be a good idea, but it depends on your use case.
(The remaining FAQ part should be translated here to keep it consistent with the original text structure)
The above is the detailed content of Quick Tip: Testing Symfony Apps with a Disposable Database. For more information, please follow other related articles on the PHP Chinese website!