cucumber
feature files in directory still expects the step definitions to be in the root
I have the following project structure
bdd_demo
\tests
\features
first.feature
first_steps.go
def.go
abc.go
go.mod
go.sum
with the above project structure when I run godog run tests/features/ it doesn't detect the step definitions already defined in the bdd_demo/tests/first_steps.go
If there is no capability to detect, then there should be a command line flag or option to specify the location of the step definitions root directory.
Hi @alwindoss, thanks for the feature request!
Where would you want to define these?
func InitializeTestSuite(ctx *godog.TestSuiteContext)func InitializeScenario(ctx *godog.ScenarioContext)
Ideally this should be at the test suite level. But if people have different project structures, we may have to consider providing this at scenario level as well.
As an example, if we take the godogs-example from godog, you would like to be able to run that example from another folder like the root-folder in the repository?
Came here looking for it, it is specially helpful if you want to have a make bdd_test that will run from the root directory. We do indeed can cd tests; godog . and it will work. But godog run directory could be helpful.
Interestingly, I have misunderstood the godog run --help thinking it was possible by the mention of a dir:
Examples:
godog run
godog run <feature>
godog run <feature> <feature>
Optional feature(s) to run:
dir (features/) <-----
needing to put the step definition "xxx_test.go" files in the root directory imho violates established golang structure principles.
godog should find those files where the go test would find them too - mainly within the appropriate package folders.
To better distinguish "bdd step definitions" and "regular test files", I started prefixing step-definitions with stepdef_ - so they stand out in the project root... (maybe a strange idea, but works for me)
needing to put the step definition "xxx_test.go" files in the root directory imho violates established golang structure principles.
godog should find those files where the
go testwould find them too - mainly within the appropriate package folders.
Go does not restrict the user on where the xxxx_test.go files exist. go test will detect all xxxx_test.go files. Generally if you are writing unit tests the test files live alongside your regular code files, if you are writing integration tests for a single package even then it makes sense having test files alongside the regular code files.
In this case I am referring to integration test suite that I want to create for an entire application which has multiple packages which are part of it and this integration test suite does not belong to any single package. In such a case a flexible project structure is warranted, where in the option to specify the location of step definitions makes sense. I hope now the ask is clearer.
I would suggest to consider using standard go test <path-or-package-qualifier> instead of godog cli tool in cases where flexible layout is desireable.
https://github.com/cucumber/godog#running-godog-with-go-test
This way you can leverage full power of standard Go and import step definitions and/or initialization facades from any relevant places of your codebase.
