-
-
Notifications
You must be signed in to change notification settings - Fork 650
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
API for accessing all defined specs #1225
Comments
thanks for adding the issue @pohly I'd like your input on some design questions. I can imagine two approaches:
I haven't considered the implementation yet and it may prove that one of these is much cheaper than the other - but I wanted to discuss the design without that bias. Thoughts? |
Can we do both? Option 2 may be useful for users to quickly try out the effect of the CLI flags. Option 1 can be achieved by not setting any flags, so option 2 is more capable. However, if in that same run one wants to report "x out of y specs would run", then one needs both. |
Just curious has there been any further progress on this? I would be interested in this functionality. In my team we've switched leveraging the |
I'm finally working on this and want to confirm that, just like |
So you mean a process can invoke either The But the PR also adds sanity checking of the test registration. I'm still discussing with Having said that, shipping it sooner with the constraint and later relaxing it sounds good to me. |
I'll take a look at allowing |
@pohly what about the constraint to run in series only? |
actually - never mind. i think i've found a way around both constraints that isn't too expensive or too ugly. i'll push it to master after I add some tests |
alrighty - sorry for all the noise. the latest code is now on master and both constraints are gone. You can call |
Excellent! I'll take a look. |
I've now also tested with |
👍 thanks @pohly - i'll cut a release now |
ginkgo --dry-run
can be useful for users to see what specs are defined. But sometimes test suite authors may want to provide other ways of listing specs or derive information about them (e.g. all defined labels). For that, aPreviewSpecs
function that returns a fullReport
would be useful.Less useful alternative: adding a "don't produce any output"
ReportConfig
field, then callingRunSpecs
with aReportAfterSuite
callback. More complicated to set up.Originally discussed in https://gophers.slack.com/archives/CQQ50BBNW/p1686938649240809.
The text was updated successfully, but these errors were encountered: