[LoadDataFixturesDoctrineCommand] doctrine:fixtures:load --env=test #34

Closed
liuggio opened this Issue Feb 20, 2012 · 17 comments

Comments

Projects
None yet
9 participants

liuggio commented Feb 20, 2012

Hi,

Usually when we develop we have more than one set of fixtures,
for example, the fixtures are many more on stage than on test
So we created two folder foreach bundle

DataFixtures / test / ORM / ...
DataFixtures / ORM / ... // stage

It would be nice if you could load a set of fixtures
depending from wich environment you select, for example for the 'dev' env.
would be loaded the fixtures in bundleName / DataFixtures / dev / ORM / ...

The solution is easy just add a parameter and add a row on the row number 90.

I could do it, what do you think?

Member

stof commented Feb 20, 2012

you can already achieve such thing with the --feature-path option giving the path to the directory to load (you can use the option several times)

liuggio commented Feb 21, 2012

Hi thanks for the reply
is not properly the same,
with --feature you have to know all the bundles path.
The solution could be put the prefix into the arguments of the command
or saving the path into the config eg. parameter.ini for the fixtures path
now is hardcoded into the php ('/DataFixtures/ORM')

So we will have foreach envorinment the correct fixtures

ptitcub commented Jul 19, 2012

indeed, --env option could be very usefull to test on each environment...

thx

liuggio commented Jul 20, 2012

@ptitcub that option already exist, but there's no way to use different fixtures for differents env

Hi, i think it's a very common usecase to have different fixtures in the environments like test,prod,dev. I understand that one could achive such behavior with the fixture parameter, but I think there should be a more convenient way to do that. Additionally I would like to recommend to have something like 'inheritance'. That would allow a set of fixtures as a base and then specializations for the environments.

ashton commented Oct 15, 2012

This feature will be really useful if integrated with Doctrine DBAL, allowing us to load test fixtures into a test database, isolating test data, instead of dirtying the development database with test data, or purging develpment database everytime you ran your application tests.. That would be so useful..

zodeus commented Nov 2, 2012

It would be nice to have some way of running certain fixtures base on some sort of criteria. However I think using an annotation such as @group on the fixture methods, with --include/exclude filter would be a better approach than separating them via directories or environments. This way you have a lot more flexibility when applying fixtures. For example you may have some fixture data related to users that you want applied to all environments but you only want to create users in test/dev.

greg0ire commented Oct 1, 2014

@ashton : There is a solution for that! In your config_test.yml file, just write this:

doctrine:
    dbal:
        dbname:   %database_name%_test

liuggio commented Oct 1, 2014

@greg0ire @ashton is better and cleaner create a parameters_test.ini for the test env.

greg0ire commented Oct 1, 2014

@liuggio Why ? parameters* files are for things that change from machine to machine.

liuggio commented Oct 1, 2014

For 2 main reasons
one explicit is always better than explicit
second in this way you have created a convention that is bad.

greg0ire commented Oct 1, 2014

explicit is always better than explicit

you mean "explicit is always better than implicit" I suppose… how i using a file named config_test.yml not explicit ? The _test part feels pretty explicit to me.

And I can't see how I'm creating a convention, this file was here in the first place. Can't see how this is bad either. You need to make more compelling arguments (or to withdraw your previous claim, which would be the way to go IMO).

liuggio commented Oct 1, 2014

ops yes was implicit.

Explicit = database_test, Implicit = something magic.
Convention = take the database name and add a test

you need to make more compelling arguments

I think you have all the arguments.

withdraw your previous claim

no comment.

greg0ire commented Oct 1, 2014

I think you have all the arguments.

Yeah sorry, I did, but you have to admit they were not very clearly expressed.

I understand how I created a convention, but I don't think it is bad at all. By putting the %database_name% parameter in the parameters.yml file, symfony-standard lets people customize their database name on a machine level. But if they think some_name is a reasonable value, that won't clash with their existing databases, then maybe we can reasonably agree on the fact that some_name_test won't clash with an existing database either, can't we ? I think you're proposing to give extra flexibility that is not really needed.

Thinking harder, I think there is one case where I might consider your proposition : If I have a CI server that has databases and I don't want to have all databases suffixed with _test. Until then, I'll stick with convention over configuration, and the following principle:

Only put in the parameters.yml file things that change from machine to machine.

Member

stof commented Oct 4, 2014

People can do what they want to configure their test environment in their project, either using a suffix to their database name, or putting a separate parameter in their parameters.yml file for the test database.
In any case, configuring the database used in your test environment has nothing to do with this issue, which is about changing the fixtures based on the environment, and is not the responsibility of this bundle

Member

lavoiesl commented Mar 23, 2015

Closing since test databases are already possible and issues already exist for selective loading: doctrine/data-fixtures#169, doctrine/data-fixtures#140

lavoiesl closed this Mar 23, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment