A functional test class relies on an object reference created in a fixture. The reference's id, however, is not identical to the object's id property as returned by the entity manager. Below is a test that demonstrates this problem.
Notes:
The error is the same when using $this->setReference(...) as when
using the public const ... and $this->addReference(...).
The object reference used in the test appears to be the next
available id for nonprofit entities.
The test class was created after the error was observed in a more general test class.
The error is the same whether or not the fixtures are loaded before
running the test class.
The application uses Symfony 5.1.2 with all dependencies updated.
Test class:
namespace App\Tests\Controller;
use Liip\TestFixturesBundle\Test\FixturesTrait;
use Symfony\Bundle\FrameworkBundle\Test\WebTestCase;
class ReferenceTest extends WebTestCase
{
use FixturesTrait;
public function setup(): void {
$this->client = $this->createClient();
$this->fixtures = $this->loadFixtures([
'App\DataFixtures\Test\OptionsFixture',
'App\DataFixtures\Test\NonprofitFixture',
'App\DataFixtures\Test\OpportunityFixture',
'App\DataFixtures\Test\UserFixture',
])
->getReferenceRepository();
$this->client->followRedirects();
$kernel = self::bootKernel();
$this->entityManager = $kernel->getContainer()
->get('doctrine')
->getManager('test');
}
public function testNonprofitReference() {
$npo = $this->entityManager->getRepository(\App\Entity\Nonprofit::class)
->findOneBy(['orgname' => 'Marmot Fund']);
$nId = $npo->getId();
$id = $this->fixtures->getReference('npo')->getId();
$this->assertEquals($nId, $id, 'Reference incorrect');
}
}
Test result:
Reference incorrect
Failed asserting that 4 matches expected 1.
NonprofitFixture (other fixtures may not be relevant):
namespace App\DataFixtures\Test;
use App\Entity\Nonprofit;
use Doctrine\Common\DataFixtures\AbstractFixture;
use Doctrine\Common\DataFixtures\OrderedFixtureInterface;
use Doctrine\Common\Persistence\ObjectManager;
use Doctrine\Bundle\FixturesBundle\ORMFixtureInterface;
class NonprofitFixture extends AbstractFixture implements OrderedFixtureInterface, ORMFixtureInterface
{
public const NPO_REFERENCE = 'npo';
public function load(ObjectManager $manager) {
$npo = new Nonprofit();
$npo->setOrgname('Marmot Fund');
$npo->setEin('123456789');
$npo->setActive(false);
// $this->setReference('npo', $npo);
$this->addReference(self::NPO_REFERENCE, $npo);
$npo1 = new Nonprofit();
$npo1->setOrgname('Turkey Fund');
$npo1->setEin('321654978');
$npo1->setActive(true);
$npo1->setWebsite('http://turkeysRUs.bogus.info');
$npo3 = new Nonprofit();
$npo3->setOrgname('Talk Trash Fund');
$npo3->setEin('978654321');
$npo3->setActive(true);
$npo3->setWebsite('http://ttrash.bogus.info');
$staff = $this->getReference(UserFixture::STAFF_REFERENCE);
$npo->setStaff($staff);
$opp = $this->getReference(OpportunityFixture::OPP_REFERENCE);
$opp1 = $this->getReference(OpportunityFixture::OPP1_REFERENCE);
$npo1->addOpportunity($opp);
$npo3->addOpportunity($opp1);
$manager->persist($npo);
$manager->persist($npo1);
$manager->persist($npo3);
$manager->flush();
}
public function getOrder() {
return 5; // the order in which fixtures will be loaded
}
}
framework.yaml excerpt:
liip_test_fixtures:
keep_database_and_schema: true
cache_db:
sqlite: liip_test_fixtures.services_database_backup.sqlite
dama_doctrine_test_bundle.yaml:
dama_doctrine_test:
enable_static_connection: true
enable_static_meta_data_cache: true
enable_static_query_cache: true
csv export from app.db:
"id","orgName"
"1","Marmot Fund"
"2","Turkey Fund"
"3","Talk Trash Fund"
The answer, such as it is, is that references have no place in a functional test. Their use is really a shortcut for clicking on links or taking some other action. A better test is to use the crawler to mimic the action.
Related
I'm running Symfony 5.4 and PHPUnit 9.5. I have a test which extends Symfony\Bundle\FrameworkBundle\Test\WebTestCase. I create an entity in my test, then execute the code under test. However, in my app's code, the entity is not to be found. I've tried finding the entity directly in the called app code and using dd() to dump it out (ending the test early), but I always get null. Somehow my test is using a different entity manager from the app code. This is how I'm fetching the entity manager:
<?php
use Doctrine\ORM\EntityManager;
use Symfony\Bundle\FrameworkBundle\Test\WebTestCase;
class MyTest extends WebTestCase {
protected EntityManager $entity_manager;
protected function setUp(): void {
$this->entity_manager = static::getContainer()->get('doctrine')->getManager();
}
public function testShouldCreateAnEntityThatIsVisibleInTheAppCode() {
$user = new User();
$user->setFirstName('Joe');
$user->setLastName('Bloggs');
$user->setEmail('joe.bloggs#example.com');
$this->entity_manager->persist($user);
$this->entity_manager->flush();
$crawler = static::$client->request('GET', 'https://localhost/admin/show-users');
$this->assertStringContainsString('joe.bloggs#example.com', $crawler->html());
}
}
How do I get my test to use the same entity manager as the code under test?
It turned out all I needed to do was add
static::$client->disableReboot();
into setUp() like so:
protected function setUp(): void {
static::$client->disableReboot();
$this->entity_manager = static::getContainer()->get('doctrine')->getManager();
}
The Symfony docs shows a solution, but it doesn't appear to work (i.e. Doctrine\Bundle\FixturesBundle\Purger\PurgerFactory needs to be replaced with Doctrine\Bundle\FixturesBundle\Purger\ORMPurgerFactory, and other changes). I modified the code as shown below, but am pretty certain I am not doing it correctly.
<?php
declare(strict_types=1);
namespace App\DataFixtures\Purger;
use Doctrine\Bundle\FixturesBundle\Purger\PurgerFactory;
use Doctrine\Common\DataFixtures\Purger\PurgerInterface;
use Doctrine\ORM\EntityManagerInterface;
use Doctrine\Bundle\FixturesBundle\Purger\ORMPurgerFactory;
class CustomPurgerFactory implements PurgerFactory
{
public function __construct(private ORMPurgerFactory $purgeFactory)
{
}
public function createForEntityManager(?string $emName, EntityManagerInterface $em, array $excluded = [], bool $purgeWithTruncate = false) : PurgerInterface
{
// Change $excluded, $purgeWithTruncate as desired.
return new CustomPurger($emName, $em, $excluded, $purgeWithTruncate, $this->purgeFactory);
}
}
<?php
declare(strict_types=1);
namespace App\DataFixtures\Purger;
use Doctrine\Common\DataFixtures\Purger\PurgerInterface;
use Doctrine\Common\DataFixtures\Purger\ORMPurgerInterface;
use Doctrine\ORM\EntityManagerInterface;
use Doctrine\Bundle\FixturesBundle\Purger\ORMPurgerFactory;
class CustomPurger implements ORMPurgerInterface
{
public function __construct(private ?string $emName, private EntityManagerInterface $entityManager, private array $excluded, private bool $purgeWithTruncate, private ORMPurgerFactory $purgeFactory)
{
}
public function setEntityManager(EntityManagerInterface $entityManager):void
{
// Seems rather redundent doing this even though I earlier inject $entityManager.
$this->entityManager = $entityManager;
}
public function purge() : void
{
// Delete any tables which must be deleted first to prevent FK constraint errors.
// This doesn't seem write.
$purger = $this->purgeFactory->createForEntityManager($this->emName, $this->entityManager, $this->excluded, $this->purgeWithTruncate);
$purger->purge();
}
}
services:
App\DataFixtures\Purger\DoctrinePurgerFactory:
tags:
- { name: 'doctrine.fixtures.purger_factory', alias: 'my_purger' }
arguments:
- '#doctrine.fixtures.purger.orm_purger_factory'
Or should it be done by decorating the default purger as suggested by this post?
Okay. So you do have a few things wrong and the docs are somewhat out of date. From a big picture point of view you want something like:
bin/console doctrine:fixtures:load --purger=my_purger
to use your custom purger factory (aliased as my_purger) to instantiate and execute your custom purger's purge method. The job of the factory is to just create the purger not to execute it.
I followed the docs and implemented PurgerInterface but the purge command complained about it not implementing ORMPurgerInterface which, as you noted, adds a seemingly superfluous method. I think it is still a work in progress. The default ORMPurger has a couple of additional public methods not defined in any interface which is also strange. The fact that Doctrine is inconsistent with it's usage of the Interface suffix does not help. But it is what it is.
This works under 6.1:
# CustomPurger.php
use Doctrine\Common\DataFixtures\Purger\ORMPurgerInterface;
use Doctrine\ORM\EntityManagerInterface;
class CustomPurger implements ORMPurgerInterface
{
private EntityManagerInterface $em;
public function setEntityManager(EntityManagerInterface $em) : void
{
$this->em = $em;
}
public function purge() : void
{
dd(' my purger');
}
}
# CustomPurgerFactory.php
use Doctrine\Bundle\FixturesBundle\Purger\PurgerFactory;
use Doctrine\Common\DataFixtures\Purger\PurgerInterface;
use Doctrine\ORM\EntityManagerInterface;
class CustomPurgerFactory implements PurgerFactory
{
public function createForEntityManager(?string $emName, EntityManagerInterface $em, array $excluded = [], bool $purgeWithTruncate = false) : PurgerInterface
{
return new CustomPurger($em);
}
}
# services.yaml
App\Purger\CustomPurgerFactory:
tags:
- { name: 'doctrine.fixtures.purger_factory', alias: 'my_purger' }
bin/console doctrine:fixtures:load --purger=my_purger
> purging database
^ " my purger"
As far as decorating goes, you decorate a service when you want to modify some methods without extending the original class. There is only one method here and it's quite a doozy so I don't think decorating will help.
If you wanted to always use your purger without the --purger option then you could probably point the default purger factory service id to your factory. I'll leave that as an exercise for the reader.
One final note: I took a look at your decorating link. Don't know what they were trying to do but I do know it has nothing to do with decorating.
As my IDE points out, the AbstractController::getDoctrine() method is now deprecated.
I haven't found any reference for this deprecation neither in the official documentation nor in the Github changelog.
What is the new alternative or workaround for this shortcut?
As mentioned here:
Instead of using those shortcuts, inject the related services in the constructor or the controller methods.
You need to use dependency injection.
For a given controller, simply inject ManagerRegistry on the controller's constructor.
use Doctrine\Persistence\ManagerRegistry;
class SomeController {
public function __construct(private ManagerRegistry $doctrine) {}
public function someAction(Request $request) {
// access Doctrine
$this->doctrine;
}
}
You can use EntityManagerInterface $entityManager:
public function delete(Request $request, Test $test, EntityManagerInterface $entityManager): Response
{
if ($this->isCsrfTokenValid('delete'.$test->getId(), $request->request->get('_token'))) {
$entityManager->remove($test);
$entityManager->flush();
}
return $this->redirectToRoute('test_index', [], Response::HTTP_SEE_OTHER);
}
As per the answer of #yivi and as mentionned in the documentation, you can also follow the example below by injecting Doctrine\Persistence\ManagerRegistry directly in the method you want:
// src/Controller/ProductController.php
namespace App\Controller;
// ...
use App\Entity\Product;
use Doctrine\Persistence\ManagerRegistry;
use Symfony\Component\HttpFoundation\Response;
class ProductController extends AbstractController
{
/**
* #Route("/product", name="create_product")
*/
public function createProduct(ManagerRegistry $doctrine): Response
{
$entityManager = $doctrine->getManager();
$product = new Product();
$product->setName('Keyboard');
$product->setPrice(1999);
$product->setDescription('Ergonomic and stylish!');
// tell Doctrine you want to (eventually) save the Product (no queries yet)
$entityManager->persist($product);
// actually executes the queries (i.e. the INSERT query)
$entityManager->flush();
return new Response('Saved new product with id '.$product->getId());
}
}
Add code in controller, and not change logic the controller
<?php
//...
use Doctrine\Persistence\ManagerRegistry;
//...
class AlsoController extends AbstractController
{
public static function getSubscribedServices(): array
{
return array_merge(parent::getSubscribedServices(), [
'doctrine' => '?'.ManagerRegistry::class,
]);
}
protected function getDoctrine(): ManagerRegistry
{
if (!$this->container->has('doctrine')) {
throw new \LogicException('The DoctrineBundle is not registered in your application. Try running "composer require symfony/orm-pack".');
}
return $this->container->get('doctrine');
}
...
}
read more https://symfony.com/doc/current/service_container/service_subscribers_locators.html#including-services
In my case, relying on constructor- or method-based autowiring is not flexible enough.
I have a trait used by a number of Controllers that define their own autowiring. The trait provides a method that fetches some numbers from the database. I didn't want to tightly couple the trait's functionality with the controller's autowiring setup.
I created yet another trait that I can include anywhere I need to get access to Doctrine. The bonus part? It's still a legit autowiring approach:
<?php
namespace App\Controller;
use Doctrine\Persistence\ManagerRegistry;
use Doctrine\Persistence\ObjectManager;
use Symfony\Contracts\Service\Attribute\Required;
trait EntityManagerTrait
{
protected readonly ManagerRegistry $managerRegistry;
#[Required]
public function setManagerRegistry(ManagerRegistry $managerRegistry): void
{
// #phpstan-ignore-next-line PHPStan complains that the readonly property is assigned outside of the constructor.
$this->managerRegistry = $managerRegistry;
}
protected function getDoctrine(?string $name = null, ?string $forClass = null): ObjectManager
{
if ($forClass) {
return $this->managerRegistry->getManagerForClass($forClass);
}
return $this->managerRegistry->getManager($name);
}
}
and then
<?php
namespace App\Controller;
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use App\Entity\Foobar;
class SomeController extends AbstractController
{
use EntityManagerTrait
public function someAction()
{
$result = $this->getDoctrine()->getRepository(Foobar::class)->doSomething();
// ...
}
}
If you have multiple managers like I do, you can use the getDoctrine() arguments to fetch the right one too.
I have a Doctrine repository class that can be used to persist a User, I don't want to check if the entity was really persisted or not, I just want to know what to do in this situation:
It's easy to test a repository method that has a return value. But in this case, I have nothing to do, and I'd like to cover 100% of the code, without making unsafe code that can break like use #addToAssertionCount.
<?php
namespace Domain\Repository;
use DateTime;
use Domain\Entity\User;
use Domain\Repository\Interfaces\UserRepositoryInterface;
class UserRepository extends Repository implements UserRepositoryInterface
{
public function create(User $user): void
{
$user->setCreatedAt(new DateTime('now'));
$this->getEntityManager()->persist($user);
}
}
And a testing class for it:
<?php
namespace Domain\Repository;
use Doctrine\ORM\EntityManager;
use Domain\Entity\User;
use PHPUnit\Framework\TestCase;
class UserRepositoryTest extends TestCase
{
private UserRepository $sut;
public function setUp(): void
{
$entity_manager = $this->createMock(EntityManager::class);
$this->sut = new UserRepository($entity_manager);
}
public function test_assert_create(): void
{
$user = $this->createMock(User::class);
$this->sut->create($user);
// What to assert??
}
}
At this point, I don't know even what to assert, once the persist() method returns void, which I can't mock.
Focusing on 100% code coverage is not a good idea and encourages writing tests that have little to no value. What does that mean? The create method has two side effects: It changes the users creation date and persists it. You could test it like this:
final class UserRepositoryTest extends TestCase
{
/**
* #var EntityManager&MockObject
*/
private EntityManager $entityManager;
private UserRepository $sut;
public function setUp(): void
{
$this->entityManager = $this->createMock(EntityManager::class);
$this->sut = new UserRepository($this->entityManager);
}
public function test_create_should_persist_entity(): void
{
$user = new User();
$user->setCreatedAt(new DateTime('2000-01-01 12:15:30'));
// validate that persist call was made
$this->entityManager->expects(self::once())
->method('persist')
->with($user);
$this->sut->create($user);
// validate that creation date was set
self::assertEqualsWithDelta(new DateTime('now'), $user->getCreatedAt(), 3);
}
}
You could go even one step further and verify that the creation date was set before the persist call was made by using the callback constraint. But then, you're pretty much checking the implementation line by line in your test. That's how people end with tests that break all the time.
So, what to do instead? Focus on the purpose of the user repository: If you put something in, you should be able to get it out. This, however, requires that you use an actual entity manager. But you wrote, that you don't want to check that the entity was actually persisted. In that case, I would rather write no tests than the example I gave above.
Hello i have problem with my test.
I'm trying to test UserFactory which is creating UserObject by UserDto data.
I dont know how to test it because factory need PasswordEncoder in dependencies.
use App\Entity\User;
use App\Service\Factory\UserFactory;
use PHPUnit\Framework\MockObject\MockObject as MockObject;
use PHPUnit\Framework\TestCase;
class UserFactoryTest extends TestCase
{
/**
* #covers UserFactory
*/
public function testShouldCreateUserObjectFromUserDto()
{
//Given
/**
* #var UserDto | MockObject
*/
$userDto = $this->getMockBuilder(UserDto::class);
//When
$userFactory = new UserFactory(/* PASSWORD ENCODER */);
$user = $userFactory->create($userDto);
//Then
$this->assertInstanceOf(User::class, $user);
}
}
namespace App\Service\Factory;
use App\Entity\User;
use Symfony\Component\Security\Core\Encoder\UserPasswordEncoderInterface;
class UserFactory
{
/**
* #var UserPasswordEncoderInterface
*/
private $encoder;
public function __construct(UserPasswordEncoderInterface $encoder)
{
$this->encoder = $encoder;
}
public function create(UserDto $dto)
{
$user = new User();
$user->setPassword($this->encoder->encodePassword($dto->plainPassword));
/**
* CODE..
*/
return $user;
}
}
Is this right? how can i test this factory which have dependencies?
i cant user __construct in my TestClass
(Hint: apparently you're using the UserPasswordEncoderInterface wrong, because it's not a PasswordEncoderInterface - the former additionally expects the User as a param, while the latter does not, which I just learned today, you might want to fix that)
In general, you have to provide all dependencies for the class to be tested. There are different approaches, essentially: Implementing a reduced version of the interface (if it's an interface), actually finding the dependency and instantiate it or use a mock and tell it what will happen to it. The latter can be done if you generally know what happens with the dependency (non-blackbox testing).
So, you could just mock the interface with some well defined behavior:
//$upe = $this->getMockBuilder(\Symfony\Component\Security\Core\Encoder\UserPasswordEncoderInterface::class)->getMock();
$upe = $this->getMockBuilder(\Symfony\Component\Security\Core\Encoder\PasswordEncoderInterface::class)->getMock();
$upe->expects($this->any())
->method('encodePassword')
// omit following line, if you don't want to check for param
->with($this->equalTo('plainPassword'))
->willReturn('encodedPassword');
and then provide that mock to your userfactory:
$userfactory = new UserFactory($upe);
this is somewhat dependant on the implementation of UserFactory though, expecting it to essentially be called in the specified way and which will return the same string always. (You can go deeper into mocking and/or implement the interface yourself to have more control)