This is rather a new feature related to doctrine, isn't it?

I don't think so, Doctrine has no integration with PHPUnit so why should we not integrate this in DoctrineBridge?

As far as I know those bridges were built in order to "connect" symfony with other libraries (e.g. Swiftmailer, ProxyManager or Doctrine) and not to connect those libraries with other stuff.

Doctrine has no integration with PHPUnit

can you elaborate that?

I understand what you mean. I'm not sure if this belongs here then.

What I meant is that I don't think Doctrine provides a base test class that allows for this kind of behavior.

@Cydonia7 I understand your point now, but I still don't think that an integration layer for symphony is the right place for that.

Furthermore I don't think whether I'd use this: in case of changes I'd simply use the ORMPurger which will be executed before every single fixture appliance. Your implementation has the problem that nothing will be written to the database level which means that everything is in the UnitOfWork, but DQL queries will produce invalid resultsets as nothing is really in the database.
In order to work with the purger on test level you might want to use sth. like the LiipFunctionalTestBundle which implemented its own fixture appliance in a generic test base class: https://github.com/liip/LiipFunctionalTestBundle/blob/master/Test/WebTestCase.php#L359

The proposed feature is nice ... but I feel like it's missing something: how do you create the database before starting to create and rollback transactions.

In some projects I use a strategy similar to LiipFunctionalTest: I run some console commands to create theSQLite test database and populate it with fixtures ... and then I make a backup copy of that database (which is just a file) and overwrite the database before running each test (see details).

The question is: should this PR provide a feature to create the test database before running the first test too ... or would that be a bad idea? Thanks.

How do you test code with multiple entity managers? I'm starting to see a nasty extending pattern here, I don't know if that's the right way to do it.

To be honest, I don't think this should be in the core of symfony on its own, it belongs more to a test package. To me this just looks like a hack tbh.

@iltar I don't know if this should go in the core or not ... but this feature has been asked for several times and even the oldest pending issue in symfony-docs repository is related to this: symfony/symfony-docs#480

Personally this is something I'd use in all my projects (at the moment I use LiipFunctionalTest bundle sometimes and a custom solution other times).

@javiereguiluz Hence I said "not on its own". I don't think in its current state it brings a lot of value or usefulness, especially not if you use multiple entity managers. I think this would be a perfect candidate of a doctrine-phpunit-bridge of some sort if you want to do it somewhat like this.

Hostnet started developing this package (for our specific case): https://github.com/hostnet/database-test-lib. Internally we use this to hook up to repository tests to generate a database per test and throw it away afterwards. I do have to note:

This behaviour is accomplished using bash. This means it will only work on systems supporting bash and having a mysql daemon or drop-in replacement installed.

I'm 👎 for adding this into the core.

Rolling back transactions in tests is just one of many approaches you could take. I wouldn't like Symfony to suggest this one's good for most projects by adding a test case like this to the core. Therefore I think class like this belongs to 3rd party extension (like the mentioned LiipFunctionalTest).

@jakzal I can't imagine a real project without tests or fixtures. That's why, in my opinion, tests with fixtures is a must for any project. What could Symfony do to help us here?

@javiereguiluz I defintly agree with the point that "tests with fixtures is a must for any project".
But symfony suggests Doctrine for interaction with an RDBMS or suggests Swiftmailer for sending emails. So why not suggesting a proven testing tool for that such as LiipFunctionalTest which is tested and works?