I couldn't get the godog CLI to work for my needs but when I plugged it into a testing.T framework, I found it very easy to use.

One thing I would like to be able to do is access the testing.T instance from a scenario so I can call T.Tempdir(). Dropping support for the godog cli will make that possible.

Hey @vearutop 👋🏻

I believe it would be useful to take into consideration the upcoming release of Go version 1.20 and its potential benefits when used in conjunction with godog for running tests against application binaries. One notable advantage is the ability to accurately calculate coverage profiles, which has previously been a limitation when running tests with the godog CLI and testing as a black box. Please check: https://go.dev/testing/coverage/.

If anyone wants to try it out already you can by executing the following:

go install golang.org/dl/go1.20rc3@latest
go1.20rc3 download
go1.20rc build -cover -v -o /path/to/your/desired/binary /path/to/your/main.go
mkdir coverage && GOCOVERDIR=coverage godog run your.feature
go1.20rc3 tool covdata textfmt -i=coverage -o=coverage.out
go tool cover -func coverage.out

The benefit of having a CLI tool, is that it improves the developer experience, specially for folks that are just getting started with godog. They don't have to read through snippets on how to set it up with TestMain, they just execute a couple of CLI commands and are already up and running. You could further double down on the developer experience by introducing additional support commands.

I do however empathize with the maintainers point of view, that of reducing inner complexity and maintainability, as that will also allow you to ship new features faster perhaps. However your users don't care about that, they just want the best developer experience they can get.

Thank you for feedback, it seems with active deprecation notice there are now more people interested in keeping CLI alive.

I think we can maybe reach a compromise on minimal maintenance burden and useful interface.
godog CLI can be simplified to a facade around go test. So instead of building and invoking instrumented binary, we could create a temporary XXX_test.go file and then execute go test [propagated-flags] XXX_test.go.

Perhaps, we can try to build an experimental prototype of such a tool that would declare and propagate all go test flags, while keeping some compatibility with original godog flags.

I will suggest to provide a good and clear document on how to generate go code from the gherkin files. I will not recommend that people should hand-craft the go code from the gherkin files. This will always lead to errors and frustrations. Therefore the cli should only be for generating the the go test files and then we can run them using go test.