UnitOfWork may not be empty at the start of test in case of database population

[FlyingDR]

Currently, the database population using traits does not include a cleanup of the identity map within Doctrine's UnitOfWork.

It causes UnitOfWork to be in a "dirty" state by the time of running the test method and may cause unexpected side effects in the test.

In my application, I have a test that fails because of entity information that is left during the database population, so the case is practical.

The solution is simple: a call of EntityManager::clear() needs to be added after loading of the fixtures

AliceBundle/src/PhpUnit/BaseDatabaseTrait.php

Lines 69 to 77 in 0dd4e9e

	static::$fixtures = $container->get('hautelook_alice.loader')->load(
	new Application(static::$kernel), // OK this is ugly... But there is no other way without redesigning LoaderInterface from the ground.
	$container->get('doctrine')->getManager(static::$manager),
	static::$bundles,
	static::$kernel->getEnvironment(),
	static::$append,
	static::$purgeWithTruncate,
	static::$shard
	);

[theofidry]

I am not sure this can be changed. IIRC there was in the past an attempt made there, but I had to revert it because it was breaking too many things.

Indeed you can get the objects from the loader in your tests in which case you want persisted objects. If you do the clear you will end up with objects you will have to persist manually

[FlyingDR]

Maybe it will be worth having an option to choose to clear UnitOfWork contents or not (e.g. via separate property), so library users will at least have control over this aspect? It may default to not clear to keep current behavior intact. It may also have an explanation of its meaning and reasons for its existence as a comment so it will be easier to understand.

At the very minimum, it needs to be mentioned in the documentation that the identity map in UnitOfWork is not empty by the time of the start of the test and that it may affect the behavior of the tested application. It took me several hours to find out the reason for the test failure which was caused by current behavior, so at least knowing about this aspect is practical.

[boonkerz]

yea because with a lot of releations the entitys does not filled up correctly.

i run into this issue: the roles doesn't load into the user entity.

[theofidry]

If you need a clear it's best to do it yourself. If it's systematic you can create a decorator service to handle this.

Otherwise you use the service to load objects and you expect those objects to be in a managed state. If not, you would need to reattach all of them.