How to Test Code that Interacts with the Database
Edit this pageWarning: You are browsing the documentation for Symfony 4.0, which is no longer maintained.
Read the updated version of this page for Symfony 6.0 (the current stable version).
How to Test Code that Interacts with the Database
If your code interacts with the database, e.g. reads data from or stores data
into it, you need to adjust your tests to take this into account. There are
many ways to deal with this. In a unit test, you can create a mock for
a Repository and use it to return expected objects. In a functional test,
you may need to prepare a test database with predefined values to ensure that
your test always has the same data to work with.
Note
If you want to test your queries directly, see How to Test Doctrine Repositories.
Tip
A popular technique to improve the performance of tests that interact with the database is to begin a transaction before every test and roll it back after the test has finished. This makes it unnecessary to recreate the database or reload fixtures before every test. A community bundle called DoctrineTestBundle provides this feature.
Mocking the Repository in a Unit Test
If you want to test code which depends on a Doctrine repository in isolation,
you need to mock the Repository. Normally you inject the EntityManager
into your class and use it to get the repository. This makes things a little
more difficult as you need to mock both the EntityManager and your repository
class.
Tip
It is possible (and a good idea) to inject your repository directly by registering your repository as a factory service. This is a little bit more work to setup, but makes testing easier as you only need to mock the repository.
Suppose the class you want to test looks like this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
// src/Salary/SalaryCalculator.php
namespace App\Salary;
use App\Entity\Employee;
use Doctrine\Common\Persistence\ObjectManager;
class SalaryCalculator
{
private $objectManager;
public function __construct(ObjectManager $objectManager)
{
$this->objectManager = $objectManager;
}
public function calculateTotalSalary($id)
{
$employeeRepository = $this->objectManager
->getRepository(Employee::class);
$employee = $employeeRepository->find($id);
return $employee->getSalary() + $employee->getBonus();
}
}Since the EntityManagerInterface gets injected into the class through the constructor,
it's easy to pass a mock object within a test:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37
// tests/Salary/SalaryCalculatorTest.php
namespace App\Tests\Salary;
use App\Entity\Employee;
use App\Salary\SalaryCalculator;
use Doctrine\Common\Persistence\ObjectManager;
use Doctrine\Common\Persistence\ObjectRepository;
use PHPUnit\Framework\TestCase;
class SalaryCalculatorTest extends TestCase
{
public function testCalculateTotalSalary()
{
$employee = new Employee();
$employee->setSalary(1000);
$employee->setBonus(1100);
// Now, mock the repository so it returns the mock of the employee
$employeeRepository = $this->createMock(ObjectRepository::class);
// use getMock() on PHPUnit 5.3 or below
// $employeeRepository = $this->getMock(ObjectRepository::class);
$employeeRepository->expects($this->any())
->method('find')
->willReturn($employee);
// Last, mock the EntityManager to return the mock of the repository
$objectManager = $this->createMock(ObjectManager::class);
// use getMock() on PHPUnit 5.3 or below
// $objectManager = $this->getMock(ObjectManager::class);
$objectManager->expects($this->any())
->method('getRepository')
->willReturn($employeeRepository);
$salaryCalculator = new SalaryCalculator($objectManager);
$this->assertEquals(2100, $salaryCalculator->calculateTotalSalary(1));
}
}In this example, you are building the mocks from the inside out, first creating
the employee which gets returned by the Repository, which itself gets
returned by the EntityManager. This way, no real class is involved in
testing.
Changing Database Settings for Functional Tests
If you have functional tests, you want them to interact with a real database. Most of the time you want to use a dedicated database connection to make sure not to overwrite data you entered when developing the application and also to be able to clear the database before every test.
To do this, you can override the value of the DATABASE_URL env var in the
phpunit.xml.dist to use a different database for your tests:
1 2 3 4 5 6 7 8
<?xml version="1.0" charset="utf-8" ?>
<phpunit>
<php>
<!-- the value is the Doctrine connection string in DSN format -->
<env name="DATABASE_URL" value="mysql://USERNAME:PASSWORD@127.0.0.1/DB_NAME" />
</php>
<!-- ... -->
</phpunit>
