-
Notifications
You must be signed in to change notification settings - Fork 249
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
Add support for testing.T in steps #100
Comments
Hi, I think testing.T is something worth considering, but I'm afraid such methods as t.Fatal are something which godog cannot handle and they will be exposed. If we can make t.Fatal or t.Error captured by godog in order to print properly the error or stop suite execution after printing it after t.Fatal then it would be possible to integrate it. |
Not sure, but somehow to test seems to manage it as well. |
This would be really nice indeed. A solution would be to do something similar as what the testify lib does and have a subset of testing.T like
|
Sorry to revive an old issue here. Is this issue still valid? Or is there a way to use testing.T now? |
Hi @tylerauerbeck, no need to be sorry and I think the issue is still valid. I would definitely like to look at doing something like @creack is suggesting, but we are a pretty small group that is currently maintaining and developing godog and we haven't prioritised this yet. If you are interested in doing some work, I would be happy to collaborate! 😄 |
Hi, if you have time, please check out the suggestion in #360 and comment there if you have would like to see changes to the draft. |
Without support for this I'm having a hard time figuring out how to integrate something like |
I acknowledge this is a dated topic by now but it seems to still be unresolved. I'm attempting to consolidate test helpers which are common across both vanilla go tests and cucumber tests (i.e. they take a I haven't written any tests yet (will open a PR here once I do), I've just been hacking together a PoC but I figured I'd throw my hat in the ring at this point and see if anyone else has a better idea about what the minimum viable change to solve this looks like: |
We've discussed this here #535 (comment). To me it seems leveraging context to pass optional |
We wrote our own cucumber runner to deal with this: https://github.com/regen-network/gocuke. It is tightly integrated with testing.T |
@aaronc did you mean https://github.com/regen-network/gocuke ? |
Yes! Looks like I accidentally linked to my personal fork |
Wow, thanks for the quick turnaround everyone. 😅 @vearutop thanks for referencing the discussion! 🙌 I did not think to look there 🤦 (I keep forgetting it's a thing) I think the main difference between my approach and the discussion is that I chose to store the Thanks for sharing @aaronc and @wichert - Regen Network tools to the rescue! 🚀 It's nice to bump into you folks again, small world 🌍 |
Summary
I built a library - a very basic version of what https://github.com/cucumber/aruba does for ruby - which is used with
go test
.Details
Using the standard library I have
testing.T
available to pass to the helpers - e.g. to mark the method viat.Helper()
. Now I would love to use it withgodog
.Question
What would you recommend to do next? I think about adding some kind of a compatibility layer to the library. Or can we have
testing.T
on steps in "godog" as well?Sorry the library is not (yet) open to the public.
@charlierudolph Would such support -
testing.T
- be helpful for your projects as well? I saw your request to add "gomega" as dep to "godog" in #95.The text was updated successfully, but these errors were encountered: