LiipFunctionalTestBundle: Conflict with dama/doctrine-test-bundle

Since the update to 2.0.0-alpha4, I have the following error on each integration test:

1) Tests\AppBundle\Controller\DefaultControllerTest::testIndex
Doctrine\DBAL\Driver\PDOException: SQLSTATE[42000]: Syntax error or access violation: 1305 SAVEPOINT DOCTRINE2_SAVEPOINT_2 does not exist

/code/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:62
/code/vendor/dama/doctrine-test-bundle/src/DAMA/DoctrineTestBundle/Doctrine/DBAL/StaticConnection.php:59
/code/vendor/doctrine/dbal/lib/Doctrine/DBAL/Connection.php:1449
/code/vendor/doctrine/dbal/lib/Doctrine/DBAL/Connection.php:1385
/code/vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php:242
/code/var/cache/test/Container1xxocvm/EntityManager_9a5be93.php:62
/code/vendor/doctrine/data-fixtures/lib/Doctrine/Common/DataFixtures/Executor/ORMExecutor.php:73
/code/vendor/liip/functional-test-bundle/src/Services/DatabaseTools/ORMDatabaseTool.php:141
/code/vendor/liip/functional-test-bundle/src/Services/DatabaseTools/ORMDatabaseTool.php:80
/code/vendor/liip/functional-test-bundle/src/Services/DatabaseTools/AbstractDatabaseTool.php:135
/code/vendor/liip/functional-test-bundle/src/Test/WebTestCase.php:281
/code/tests/AppBundle/Controller/WebTestCase.php:35

First, I was thinking about a DoctrineTestBundle issue, so I gave more reports in https://github.com/dmaicher/doctrine-test-bundle/issues/58.

But I didn’t update this bundle and the issue does not exist anymore if I rollback to 2.0.0-alpha3 version of your bundle.

I suspect the backup/restore services introduced in #398 to cause side effects to doctrine-test-bundle, but I didn’t get into investigation yet.

What do those services? Probably same things? There is a way to deactivate them?

Regards.

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Reactions: 1
  • Comments: 48 (29 by maintainers)

Most upvoted comments

Hi, I also experienced this conflict with DAMA and Liip bundles with the same problem. I am using 1.9.1 version of the LiipFunctionalTestBundle. I applied @alexislefebvre fix in my project and everything works correct.

Hi @alexislefebvre, I want clarify DAMADoctrineTestBundle and LiipFunctionalTestBundle don’t do the same thing. DAMADoctrineTestBundle - create static connections and cache metadata, work only with Mysql LiipFunctionalTestBundle - create db, update schema and make database backup (not only metadata), working with all databases

I’ll give a try on my next project upgrade section, thanks!

Sorry @alexislefebvre I didn’t get the time to test.

No problem. 😃

So if I well understand, I have to migrate to v3 with the new test-fixtures bundle to get the fix?

Exactly, then you’ll be have a setting to disable changes related to database and schema: https://github.com/liip/LiipTestFixturesBundle/blob/836599c15fa6d7333aef1a60f68f3c55fe5ca7ae/doc/caveats.md

https://github.com/liip/LiipTestFixturesBundle/pull/15 has been merged, you can disable automatic creation of database in the last release of LiipTestFixturesBundle: https://github.com/liip/LiipTestFixturesBundle/releases/tag/1.1.0

Thanks for the reminder, I forgot this option. I’ll try to find a way.

I think the philosophy of fixtures loading of thoses two bundles (dama & liip) are incompatible and cannot really be mixed.

Indeed this bundle allows you to specify a different set of fixtures for every tests (at least I’m using extensively loadFixtures([Foobar::class, Bar::class]) in one test and loadFixtures([Foo::class]); in another), whereas dama’s doctrine bundle encourage you to load all fixtures once and never change it again because it will be rollbacked to the “initial” state with your fixtures after changes.

Issuing commands like CREATE ALTER etc will not make it fail; the only issue is in the fact that those commands have implicit transaction commit, so you should check after the test if the data was rolled back or not.

@Soullivaneuh

Could we consider a revert of #398 or a impler way to disable it waiting a proper fix?

I would prefer a way to disable the feature instead of reverting the numerous changes from #398.

@alekseytupichenkov started to work in #462 and I would prefer to use a simple solution a release beta and stable versions before the end of this year.