Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Load fixture without a file path #245

Open
alexislefebvre opened this issue Nov 10, 2023 · 7 comments
Open

Load fixture without a file path #245

alexislefebvre opened this issue Nov 10, 2023 · 7 comments

Comments

@alexislefebvre
Copy link
Collaborator

alexislefebvre commented Nov 10, 2023

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 #64 (comment)

@alexislefebvre
Copy link
Collaborator Author

@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
Copy link

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
Copy link

vulkanosaure commented Nov 11, 2023

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
Copy link
Collaborator Author

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
Copy link

vulkanosaure commented Nov 13, 2023 via email

@alexislefebvre
Copy link
Collaborator Author

alexislefebvre commented Nov 13, 2023

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
Copy link

vulkanosaure commented Nov 13, 2023 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants