docs: add a note about using make:factory --test

[ttskch]

Closes #786

[nikophil]

this is very relevant!

I don't know if you dug into some old PRs, but this is very related to this comment. Thus, I think this fixes #786

I'm even wondering if we should not add this to the Foundry's recipe.
Actually, I think we should do this in config/packages/zenstruck_foundry.yaml, but I'm not 100% convinced, WDYT?

@kbond any thoughts? We talked about this few months ago

[nikophil]

I don't think the problem is about "entities [which] has some properties with Doctrine relationships"

I think the problem this resolves is something like:

When using --test flag, we're still dealing with dev environment. And because we want the container to know about our factories, we need to declare them as services even if they are in the test directory. To do that, add the following to your services.yaml

don't hesitate to rephrase, this problem is hard to explain in a meaningful way

[ttskch]

@nikophil

Oh, I thought I'd looked into the old issue/PR, but I overlooked it.

You're right. I also think that registering files under tests/ in the service container in the dev environment is a strange workaround. (I don't think a fundamental solution will be possible anytime soon, so I wanted to at least document it to clear up any current user confusion.)

Essentially, I think the solution outlined in your comment below would be preferable.

Or maybe we should add a configuration node in which users can declare where they store their factories, so that we can tag them (or maybe no need to tag, at least add them in another way to the FactoryMap)

In my opinion, ideally, the make:factory command shouldn't use service container tags as a way to obtain a list of existing factories.

The basic premise is that the --test and the --namespace options are very useful and shouldn't be abolished. Given that, it's natural to assume that "existing factories" can exist in both src/ and tests/ (or another folder that's only loaded in other environments).

Therefore, the way make:factory obtains the list of existing factories should be decoupled from the service container.

In my opinion, simply hard-coding the list of folders in zenstruck_foundry.yaml would be sufficient. What do you think?

[nikophil]

In my opinion, simply hard-coding the list of folders in zenstruck_foundry.yaml would be sufficient. What do you think?

not sure to agree, loading classes based on their path brings some boilerplate code which I'd prefer to not add here (is this psr4 ? psr0 ? etc...)

I think the best solution (well... the least worth solution 😅) is to document this the way you've already done it.

Please could you adapt the PR with the following:

• change the wording to something like suggested in
• add it as a .. tip::
• I do think we should advocate to add this to packages/zenstruck_foundry.yml I even think we could add a tip in the recipe, maybe as some commented code, with a link to the documentation

thanks!

(hey this PR is the 1000th! 🎉)

[ttskch]

@nikophil I've updated this PR and also submitted a PR to recipe.

Note that since we assume that the configuration will be written in zenstruck_foundry.yaml rather than services.yaml, the value of the resource field has been changed from '../tests/Factory/' to '../../tests/Factory/', and the autowire and autoconfigure settings have been moved under the App\Tests\Factory\ key instead of _defaults.

(Congrats on 1,000 (PR|Issue)s 🎊)

[nikophil]

Can't we use %kernel.root-dir%?

[ttskch]

@nikophil Surely! (It's %kernel.project_dir% though) I fixed it like that👍

• 19da7a8
• symfony/recipes@fec4535

[nikophil]

thanks @ttskch