godog not recognizing the implemented step definition

[ruchira907]

Hi,

I am working in a golang project where in I am writing the gherkin steps and writing step definition
generated by using godog.

My package structure is:

project 's outermost directory contains:
---features(This directory in turn contains below two things)
---features(this is the directorywhich contain .feature files)
-- implemented_step-definition.go file
---Makefile( this is at the same level as outermost features directory)

The issue is that when I run godog with cucumber option under my project 's outermost directory, it recognizes the feature files under the features directory and generates the boiler plate code but it does not run the already implemented step definitions.

Please help me on this .How to make godog run the implemented step definitions from my project's
outermost directory

Thanks,
Ruchira

[l3pp4rd]

Hi,

godog acts like go test command. your step definitions should be in _test.go files in order to prevent compiling them in production code.

All step definitions needs to be registered in godog.Suite all functions AnuthingContext(s *godog.Suite) are invoked for registering steps. Note, that the context function should be exported - start with capital.

godog should be run in root package where your step definitions are in _test.go files. In order to see what step definitions godog finds, you can run godog -d that will list all detected step defs.

You can have a look at examples directory in godog or godog package itself. in order to see how a project and steps are setup. If you still struggle to find the cause, then you can simply create a minimal project with your layout which does not work, so I could help you.

Regards,
Gedi

[ckstettler]

What isnt clear in the original issue is that in our configuration features and step definitions exist in multiple child folders. Everything works fine if we run godog from somefunc, and somefunc2 where the steps exist but obviously we are running only one set of tests at a time and not all.

project-root
|----features
|       |----somefunc
|       |       |----features
|       |       |       |---- f1.feature
|       |       |       |----f2.feature
|       |       |---step_defs_test.go
|       |----somefunc2
|       |       |----features
|       |       |       |---- g1.feature
|       |       |       |----g2.feature
|       |       |---step_defs_test2.go

If we run godog from project-root ALL feature files appear to be located just fine, however, the step defs are dont found and executed.

Your 3rd paragraph in the response seems to say what we see. It seems that even though feature files can be split up and spread out across the folder structure, the step defs cannot. Godog is looking for one context in the current folder?

So to run all tests across the multiple step defs and contexts then we need to run godog multiple times -- once from the location of each step def file?

[l3pp4rd]

when you run go test it compiles _test.go files only from current package directory. because it operates within a package only. (a package is your world). same as godog.
All imported packages by the package you are testing, are compiled without _test.go files.

I've made godog to be close to go test command and follow the same rules. and your godog test files should be per package only.

The idiomatic structure should be:

project-root
|----features
|       |----somefunc
|       |       |----features
|       |       |       |---- f1.feature
|       |       |       |----f2.feature
|       |----somefunc2
|       |       |----features
|       |       |       |---- g1.feature
|       |       |       |----g2.feature
|----step_defs_test.go
|----step_defs2_test.go
|----main.go

Otherwise project-root/features/somefunc/features package is bogus since it does not contain go source. If you are coming from cucumber ruby then this is a little bit different, but that is the way it is. If you want to split steps into separate contexts - split them in separate files, but at the same package level.

[ckstettler]

I see. Actually I think I missed the fact that go test works similarly. I was thinking go test traversed the tree.

We have decided to collapse this structure as a result. Thank you for you responses.

[l3pp4rd]

go test can traverse if you tell it to, but it will compile and run tests for each package separately, godog simply does not provide such option yet, as it is not necessary in most of the cases, because most of users holds on to feature set in core project package including all step definitions in test.go files.

and that is an idiomatic way in my opinion, because these are not unit tests and usually you test the public application interface, which is exposed to user (weather it is UI, API or CLI) and that is usually a core project directory or cmd/name dir where users put all their features and step definitions. This is the encouraged way to do project layout.

If you put your tests in project root directory including go unit tests, then you get the benefit to use TestMain function in order to get combined go code coverage. This way is also encouraged and it still allows to run godog command separately if different command options are needed. You can also customize TestMain function with cli options when you run tests, like for example controlling verbosity go test -v.

From the first look godog may seem to lack features, but these are easily composed if you think the go way of doing things.

[ckstettler]

I appreciate your insights on this. We have adjusted our perspective accordingly. Thank you!

[linuxramu]

Hey hi, i am having the similar issue.

i have written the same code which is mentioned in TestMain, but when i run "go test" it was not able to find the implemented steps.

any help..!!

[l3pp4rd]

hi @linuxramu it just may mean two things

1. either you haven't hooked the step with context into test suite
2. or the step regexp does not match the step

running godog -d should show the step definitions. If you see there your step, then you can eliminate 1. Now what relates to 2, create a small test and try to match regexp you use in step to the actual step test you are testing.

[linuxramu]

thanks for reply, when i ran godog -d, i could see my steps so i am eliminating 1.

I couldnt get your 2, can you please give some examples.

Also let me give you more info that

1. When running my one feature with godog, it runs pefect

My folder structure looks like

  tests
         features
                 tasks.feature
  tasks_test.go

So when I run godog tasks.feature from below location, it runs and gives me result correctly

c:> mainfolder> tests> godog features/tasks.feature

Since my code is growing and i am having more features, now I need to write a driver test or a main test which runs the features as tagged or needed, so thats when this issue is...

I have followed to write MainTest as mentioned here : https://github.com/DATA-DOG/godog#running-godog-with-go-test

but no luck :(

[l3pp4rd]

with 2. I mean that the regular expression you use is incorrect and it does not match the step. so I'm suggesting to test your regullar expression used for the step definition.

godog itself uses godog to test himself. look at this repository how it uses features and how they are structured in the project. the directory you run godog from, must contain all the go files needed for your tests.