-
-
Notifications
You must be signed in to change notification settings - Fork 77
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
Behat Integration #235
Comments
I would create only one extension, which can do either of this behavior based on configuration. That's more idiomatic Behat. As said in #234 (comment) , it might also be worth to investigate if not using the foundry bundles can work with Behat (and setting up Foundry in the Behat extension). Given Behat separates the tests from your application container, it doesn't make much sense to have foundry registered in the test env of the app. |
Would that mean you couldn't use stories/factories with services injected or is there an avenue to support this? |
When using the https://github.com/FriendsOfBehat/SymfonyExtension Behat extension, your Behat context classes can be autowired in the Symfony container. A fresh instance of the container can be constructor-injected into context classes. That being said, I think with a context class like the following is all you'd need (needs to be listed in <?php
namespace Zenstruck\Foundry\Test\Behat;
use Behat\Behat\Context\Context;
use Symfony\Component\DependencyInjection\ContainerInterface;
use Zenstruck\Foundry\ChainManagerRegistry;
use Zenstruck\Foundry\Factory;
use Zenstruck\Foundry\Test\LazyManagerRegistry;
use Zenstruck\Foundry\Test\TestState;
class FoundryContext implements Context
{
private ContainerInterface $container;
public function __construct(ContainerInterface $container)
{
$this->container = $container;
}
/**
* @BeforeScenario
*/
public function setUpFactories(): void
{
TestState::bootFromContainer($this->container);
Factory::configuration()->setManagerRegistry(
new LazyManagerRegistry(function (): ChainManagerRegistry {
return TestState::initializeChainManagerRegistry($this->container);
})
);
}
/**
* @AfterScenario
*/
public function tearDownFactories(): void
{
TestState::shutdownFoundry();
}
} This code is almost 100% copied from The only thing I am unsure about is why |
Thanks, I think we should indeed add this context.
This is required so the start of your test doesn't have the kernel booted (which causes an error if trying to create a client). I don't know this is an issue with Behat so we probably don't have to shutdown the kernel. |
The kernel passed into contexts by the aforementioned extension is already booted for reasons, so this should be fine. Does it make sense to provide such a context in this repo here, since that might either introduce unwarranted Composer dependency declarations and/or leave us with no good rules in |
I think so, it would be a dev dep so as long as there are no conflicts, I'm fine adding here. What would be the requirement? Just |
Started a draft PR (#378). I'm going to need some help there... |
Based on discussion in #234 and looking at dmaicher/doctrine-test-bundle#128. I'm thinking we could provide 2 contexts/extensions (not sure what would be appropriate):
ResetDatabaseContext/Extension
: similar to theResetDatabase
PHPUnit traitFactoriesContext/Extension
: similar to theFactories
PHPUnit trait@wouterj, wdyt?
The text was updated successfully, but these errors were encountered: