-
Notifications
You must be signed in to change notification settings - Fork 56
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
EZEE-2718: Adjust tests for redirects #900
Conversation
@@ -15,13 +15,6 @@ class Hooks extends RawMinkContext | |||
{ | |||
use KernelDictionary; | |||
|
|||
/** @BeforeScenario |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've decided to use this opportunity to remove this, I don't think we need it and it causes failures from time to time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not entirely sure what do you mean by 5. option (so I'll be happy to talk about it when you'll work on it), but fix itself is fine for me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 to unblock tests.
@mnocon is this ready for merge? |
@lserwatka yes, this one can be merged |
Great work! Could you merge it up? |
Done |
After https://jira.ez.no/browse/EZEE-2718 the behaviour after Trashing a content item has changed:
Before:
Trashing a Content Item that has a Landing Page as a parent redirects to the Parent in Content View
After:
Trashing a Content Item that has a Landing Page as a parent redirects to the Parent:
This is a bit tricky, as we don't have a mechanism right now to deal with logic like this.
Possible solutions:
I'm not a fan of this, but it works - we need to think of a better approach for future uses.
I've decided against at as it does not work for use cases like "I want to run AdminUI suite on ezplatform-ee (we would have to define the suite twice, with the different Context being the only difference)
ezplatform
andezplatform-ee
and filtering it in suites:Again, this does not work for use case "I want to run AdminUI suite on ezplatform-ee"
ezplatform
andezplatform-ee
and filtering in an BeforeScenario hookThis works, but only partially - the ezplatform-ee scenario might require steps that are not defined in any AdminUI Context, so it will fail when running with --strict flag because of undefined steps
I've an idea how to do it, but it's not something I can do right now.