Allow modifying attribute values before calling Doctrine's find() method?

[wouterj]

Related to https://github.com/zenstruck/foundry/issues/105 and I've also had some similar use cases in the projects I'm working on.

Currently, you can't do UserFactory::repository()->assertExists(['username' => 'jane_admin', 'password' => 'kitten']); (or findOrCreate()). The issue is that the generated SELECT query uses the plaintext kitten password. In a afterInitialisation() callback, this plaintext password is hashed before saving to the database.

Maybe Foundry should have a way to consistently run a callback on attributes (independent if the attributes are used in create() or find() or assertExists())?

[kbond]

This is different from https://github.com/wouterj/symfony-demo/blob/fc122b2615652934a66acddfb6cb26241c883235/tests/Command/AddUserCommandTest.php#L108, correct?

[kbond]

My initial vision for Foundry and how I personally use it is as a direct interface to the database row. I'm not opposed to such a feature but feel it might add a lot of complexity. I somewhat resisted "Factories as Services" for the same reason.

In your example above - what about creating 2 constants: DEFAULT_PASSWORD=kitten & DEFAULT_HASHED_PASSWORD=(prehashed kitten) and use these in your tests? This would solve this issue and remove the need for your factory to be a service (it wouldn't need the password encoder). You'd get at least a little speed boost here too (and depending on your config, possibly a substantial speed boost)

[wouterj]

This is different from https://github.com/wouterj/symfony-demo/blob/fc122b2615652934a66acddfb6cb26241c883235/tests/Command/AddUserCommandTest.php#L108, correct?

Yes, I guess that's a Doctrine error. If that error is fixed, and this is resolved (I need to think about your 2nd comment), we can remove all custom assertions in that test and rely on assertExists(). This means we no longer have to support #105