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

Behat Integration #235

Open
kbond opened this issue Jan 3, 2022 · 7 comments · May be fixed by #378
Open

Behat Integration #235

kbond opened this issue Jan 3, 2022 · 7 comments · May be fixed by #378
Labels
enhancement New feature or request

Comments

@kbond
Copy link
Member

kbond commented Jan 3, 2022

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):

  1. ResetDatabaseContext/Extension: similar to the ResetDatabase PHPUnit trait
  2. FactoriesContext/Extension: similar to the Factories PHPUnit trait

@wouterj, wdyt?

@kbond kbond added the enhancement New feature or request label Jan 3, 2022
@wouterj
Copy link
Contributor

wouterj commented Jan 6, 2022

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.

@kbond
Copy link
Member Author

kbond commented Jan 6, 2022

Would that mean you couldn't use stories/factories with services injected or is there an avenue to support this?

@mpdude
Copy link
Contributor

mpdude commented Dec 1, 2022

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 behat.yml).

<?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 Factories trait (https://github.com/zenstruck/foundry/blob/1.x/src/Test/Factories.php).

The only thing I am unsure about is why Factories performs a kernel shutdown... is that necessary?

@kbond
Copy link
Member Author

kbond commented Dec 1, 2022

Thanks, I think we should indeed add this context.

The only thing I am unsure about is why Factories performs a kernel shutdown... is that necessary?

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.

@mpdude
Copy link
Contributor

mpdude commented Dec 1, 2022

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 suggests or conflicts?

@kbond
Copy link
Member Author

kbond commented Dec 1, 2022

Does it make sense to provide such a context in this repo here

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 friends-of-behat/symfony-extension?

@kbond
Copy link
Member Author

kbond commented Dec 7, 2022

Started a draft PR (#378). I'm going to need some help there...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Development

Successfully merging a pull request may close this issue.

3 participants