liip / LiipTestFixturesBundle

This bundles enables efficient loading of Doctrine fixtures in functional test-cases for Symfony applications
https://liip.ch
MIT License
165 stars 45 forks source link

Load fixture without a file path #245

Open alexislefebvre opened 10 months ago

alexislefebvre commented 10 months ago

from my understanding, we always have to define our fixture in a separate class, what i would really like is to define the fixture data inside my test function, (maybe not always but at least sometimes)

i really like the idea of having a tight coupling between a test and the specific data it requires, to avoid creating some kind of global state that will be likely to break at scale.

Is there any way to achieve that with your lib ? something like

$this->databaseTool->loadFixturesInline(function(){ //define fixture code here... });

Originally posted by @vulkanosaure in https://github.com/liip/LiipTestFixturesBundle/issues/64#issuecomment-1805054667

alexislefebvre commented 10 months ago

@vulkanosaure loadFixtures() accept an array of classes: https://github.com/liip/LiipTestFixturesBundle/blob/2.x/doc/database.md#load-fixtures-

In theory, it should work if you define a class in your test file, then provide that class to the loader.

vulkanosaure commented 10 months ago

Thanks, that would be already better, but would still be a class definition available to all test function. What I would really like is the fixture definition to be local to the test function, to forbid the possibility of another test messing up with those data and garantee a full isolation.

vulkanosaure commented 10 months ago

I used a horrible hack with $GLOBALS in the mean time, where the test function defines a function in $GLOBALS and the fixture calls it, then the test erase it

but i'd prefer to avoid something like that.

alexislefebvre commented 10 months ago

Thanks, that would be already better, but would still be a class definition available to all test function. What I would really like is the fixture definition to be local to the test function, to forbid the possibility of another test messing up with those data and garantee a full isolation.

Could you please explain the use case? How could you encounter the case of “another test messing up with those data”?

vulkanosaure commented 10 months ago

Other test functions (from the same file) would be able to execute this fixture, so to use the same test data.

Let's say we write another test and want to use the same fixture, but we have new requirements so we will want to modify (manually) the data in that fixture to fit the new test, and potentially break the previous test.

It happened to me in a previous project where I was using a single database dump for all my tests.

On Mon, 13 Nov 2023, 18:55 Alexis Lefebvre, @.***> wrote:

Thanks, that would be already better, but would still be a class definition available to all test function. What I would really like is the fixture definition to be local to the test function, to forbid the possibility of another test messing up with those data and garantee a full isolation.

Could you please explain the use case? How could you encounter the case of “another test messing up with those data”?

— Reply to this email directly, view it on GitHub https://github.com/liip/LiipTestFixturesBundle/issues/245#issuecomment-1808019303, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABGJ2XB64TBOD3TY7WHWO73YEIDC7AVCNFSM6AAAAAA7GKPIMOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBYGAYTSMZQGM . You are receiving this because you were mentioned.Message ID: @.***>

alexislefebvre commented 10 months ago

Yes this is a common issue, when we start a project we have one fixture, then we need to test another behaviour with different data. And the project grows and more cases must be covered by tests.

You may create a fixture for every case but you'll end up with lot of duplicated code.

I would instead recommend to load the same base fixture but update it with the data you need before running the test, so that you only modify what you want.

Something like this:

$entity = $this->myEntityRepository->findOneBy(['name' => 'fixture']);
$entity->setProperty('the value I need');
$this->flush();

$this->assert…
vulkanosaure commented 10 months ago

Ok that looks like an interesting idea. I was indeed thinking that I would need at least something common, to avoid duplicating too many fixture.

I'll give this a try, thanks

On Mon, 13 Nov 2023, 19:31 Alexis Lefebvre, @.***> wrote:

Yes this is a common issue, when we start a project we have one fixture, then we need to test another behaviour with different data.

You may create a fixture for every case but you'll end up with lot of duplicated code.

I would instead recommend to load the same base fixture but update it with the data you need before running the test, so that you only modify what you want.

Something like this:

$entity = $this->myEntityRepository->findOneBy(['name' => 'fixture']);$entity->setProperty('the value I need');$this->flush(); $this->assert…

— Reply to this email directly, view it on GitHub https://github.com/liip/LiipTestFixturesBundle/issues/245#issuecomment-1808079114, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABGJ2XAWB4RKZL7NWZNV4CTYEIHLVAVCNFSM6AAAAAA7GKPIMOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBYGA3TSMJRGQ . You are receiving this because you were mentioned.Message ID: @.***>