Add support for testing.T in steps

[maxmeyer]

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 https://github.com/DATA-DOG/godog/issues/95.

[l3pp4rd]

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.

[maxmeyer]

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

[creack]

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]

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

[lonnblad]

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]

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]

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]

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:

https://github.com/bryanchriswhite/godog/pull/1

[vearutop]

We've discussed this here https://github.com/cucumber/godog/discussions/535#discussioncomment-5134474.

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

[aaronc]

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

[wichert]

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

[aaronc]

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

Yes! Looks like I accidentally linked to my personal fork

[bryanchriswhite]

Wow, thanks for the quick turnaround everyone. :sweat_smile:

@vearutop thanks for referencing the discussion! :raised_hands: I did not think to look there :facepalm: (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! :rocket:

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