-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Allow single #[Examples] attribute #6812
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
base: main
Are you sure you want to change the base?
Conversation
#[Examples(1, 1)] | ||
#[Examples(2, 2)] |
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.
As already mentioned in #6752 (comment) this is a slight BC break introduced by this PR.
However, the behavior doesn't seem to be documented and from DX perspective I would prefer the new behavior.
Any thoughts about this are welcome.
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.
The first syntax allows for dereferencing from arrays using ...
. also what about generators? They can't use the 2nd Syntax
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.
The first syntax allows for dereferencing from arrays using
...
.
Shouldn't this still be possible by just passing an array as example, f.e. #[Examples(['foo' => 'bar'])]
? Please correct me if I misunderstood the problem.
what about generators? They can't use the 2nd Syntax
Do you mean that the new syntax breaks generators? Can you provide an example?
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.
@SamMousa Any news about this?
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 dont remember exactly.
But I'll say this: to me having a different behaviour depending on the type of argument given to the attribute is bad design, both from a code quality as well as a DX perspective.
I don't remember this PR (it's been a while, so feel free to ignore this comment and merge if you like it.
4ecaaad
to
c2a260f
Compare
@W0rma OK, here's what I think about it: If this introduces a BC there is no alternative but to point it to the next major version You can integrate this right now by creating a way to manually activate it with the old behavior being the default. I prepared a PR of how I imagine you could implement it: W0rma#1 You would have to add documentation here and there and think of better names for the flag, but this is the only way I see to add this in Plan C is to make a new .yml configuration parameter for this. I agree with SamMousa that this could still be designed better, so it would be a feature marked as experimental (in other words, we are not yet going to deprecate current behavior). |
Fixes #6726
The current implementation of the
#[Examples]
attribute differs from what is documented at https://codeception.com/docs/AdvancedUsage#Examples-Attribute (reported in Codeception/codeception.github.com#870).Futhermore, it is currently not possible to use a single
#[Examples]
attribute in a test.This PR is based on #6752 which was closed automatically a few months ago and fixed the behavior.
This PR replaces #6789 which is about the same issue.