-
Notifications
You must be signed in to change notification settings - Fork 62
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
Interacting with the driverContainer doesn't work when running multiple scenario in a row #149
Comments
Updated issue with a reproducer |
Yesterday, I communicated with @silverbackdan on another issue related to this one (Kocal/SymfonyMailerTesting#17) He gave me the trick to solve this issue: calling The issue is that the driverContainer injected in contexts ( All other call to The "hack" is to set the Let make some 2 diagrams:
There are 3 approaches:
This should be configurable or well documented. I stopped to use behat in many situations because of that and instead relied on PhpUnit.
This will work in simple scenario. When you have more than one
To me, it will totally solve the issue. But I fear the impact and eventual BC breaks it could imply. This is a question I would like to ask to @symfony/symfony core contributors. Another solution is to extend the What do you think about this? |
(I have not read/understood this yet) But maybe @kbond should also be pinged. Btw, your handwriting is awesome! |
I think this looks like you want to mock a service. My first thought is to check out https://github.com/Happyr/service-mocking which helps with this. I've only used with phpunit but think it could be used with behat. |
Thanks to you both @Nyholm and @kbond for the reaction. Actually, the error rely on who the kernel work in behat. You can assume the Mock a service part is working as expected. The issue is: The same test won't pass 2 times in a row, like in this reproducer. |
I'm not 100% sure about the kernel/container with behat. I just know that setting/maintaining container state in tests/between requests can be troublesome in general. That being said, it does seem like a bug in behat/this extension - you'd expect a clean slate between scenarios.
This seems like the crux of the problem. I don't know enough about this extension/behat to know how to fix. |
@kbond Thanks for your answer.
I agree with you on that ! But, in this case, we have a clean state between scenarios and steps. And I think it's a bit too much. What do you (all) think about this? Should we clean the state between steps? Thus, the first executed scenario won't have a clean state but the 2...n scenarios will have a clean state which is inconsistent. This reinforces my idea that there is something to change here. Before going futher (eg: a PR), I would like to have the opinions of other developers. |
I have a suggestion in #190 to
Not quite sure, but I think both parts are needed to get a clean separation. Note that when you do make two (or more) requests from within a single scenario, you have no good place to interact with the |
Tests deal with behavior around FriendsOfBehat#149
Tests deal with behavior around FriendsOfBehat#149
Tests deal with behavior around FriendsOfBehat#149
@develth could you please open a new issue providing a (hopefully simple) reproduce case? |
Hi there !
I'm using this very new feature in order to manipulate a mocked symfony HTTP client. I need to ensure my application behave well when receiving specific response from external services (such as 500).
Where is the scenario I want to test: When I try to ban a user, if its sessions haven't been deleted from our gateway (which use redis), I refuse the transition and keep the current state => so that the backoffice user can retry until the session are terminated.
Under the hood, I'm manipulating my mocked http client:
If I run this scenario alone
vendor/bin/behat features/user/ban.feature:65
, it works !But I run all the file, it fails
vendor/bin/behat features/user/ban.feature
:The gateway client have a null result, maybe the service wasn't called ? (Exception)
=> which means the instance of GatewayClient::class I have in my behat context hasn't been used.
reproducer
The text was updated successfully, but these errors were encountered: