Skip to content
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

Open
maxmeyer opened this issue Sep 14, 2017 · 13 comments
Open

Add support for testing.T in steps #100

maxmeyer opened this issue Sep 14, 2017 · 13 comments
Labels
❓ question Consider using support forums: https://cucumber.io/tools/cucumber-open/support

Comments

@maxmeyer
Copy link
Member

maxmeyer commented Sep 14, 2017

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 via t.Helper(). Now I would love to use it with godog.

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.

@l3pp4rd
Copy link
Member

l3pp4rd commented Sep 14, 2017

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.

@l3pp4rd l3pp4rd added the ❓ question Consider using support forums: https://cucumber.io/tools/cucumber-open/support label Sep 14, 2017
@maxmeyer
Copy link
Member Author

Not sure, but somehow to test seems to manage it as well.

@creack
Copy link

creack commented Aug 18, 2018

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

// TestingT is an interface wrapper around *testing.T
type TestingT interface {
        Errorf(format string, args ...interface{})
        FailNow()
}

@tylerauerbeck
Copy link

Sorry to revive an old issue here. Is this issue still valid? Or is there a way to use testing.T now?

@lonnblad
Copy link
Member

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! 😄

@lonnblad
Copy link
Member

lonnblad commented Mar 5, 2021

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.

@aaronc
Copy link

aaronc commented Feb 17, 2022

Without support for this I'm having a hard time figuring out how to integrate something like gomock where the Controller needs to be initialized with something resembling testing.T: https://pkg.go.dev/github.com/golang/mock@v1.6.0/gomock#NewController

@bryanchriswhite
Copy link

bryanchriswhite commented May 9, 2023

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 *testing.T and call t.Helper() conventionally). Additionally, we are using gomock in some of these helpers which puts me in the same boat as @aaronc.

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:

bryanchriswhite#1

@vearutop
Copy link
Member

vearutop commented May 9, 2023

We've discussed this here #535 (comment).

To me it seems leveraging context to pass optional *testing.T via type-safe accessor is still the best option, wdyt?

@aaronc
Copy link

aaronc commented May 9, 2023

We wrote our own cucumber runner to deal with this: https://github.com/regen-network/gocuke. It is tightly integrated with testing.T

@wichert
Copy link
Contributor

wichert commented May 9, 2023

@aaronc did you mean https://github.com/regen-network/gocuke ?

@aaronc
Copy link

aaronc commented May 9, 2023

@aaronc did you mean https://github.com/regen-network/gocuke ?

Yes! Looks like I accidentally linked to my personal fork

@bryanchriswhite
Copy link

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 testing.T in the context to avoid having to dealing with the complexity of all the reflection that's going on. I agree that the UX is better the way it's proposed in the discussion.


Thanks for sharing @aaronc and @wichert - Regen Network tools to the rescue! 🚀

It's nice to bump into you folks again, small world 🌍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
❓ question Consider using support forums: https://cucumber.io/tools/cucumber-open/support
Projects
None yet
Development

No branches or pull requests

9 participants