Is godog production ready

[anishnagaraj]

I am new to golang. I am basically from an Infra team. We have some Infrastructure as code and there are very specific configurations and integrations that we want to test which is BDD based. I suggested to my team that we should pick a BDD framework that is Golang based as we are planning to predominantly use it for our automations and development of custom resource definition.

I tried basic godog example so far by adding multiple other scenarios and the basics looks fine until now. But I am unable to decide if godog is good enough for production because of the lack of documentation. I am looking to see how I can do the following

1. Run a Suite of Test cases where test cases are written in different files
2. Achieve test fixtures, where I have the control on the order in which the testcases should run

The community's input is very much appreciated.

[mirogta]

Hi,

I'm probably not one to decide of godog is production ready, I'll leave it up to the authors/co-authors, but I'm happy to share my own point of view: I have been using godog successfully in production for years. With caveats (below). Also for building BDD based infrastructure testing. The community seems to be somewhat active and the project isn't completely dead. Go for it! In fact, if you do, do you think you would be able to also contribute back to godog?

• If you're using https://github.com/stretchr/testify for assertions (like we do), then it can be a problem. godog can support stretchr/testify asserts OOB, but it's very hairy and not done in the typical way - see assert-godogs. I've built a separate library to work around that. See an example here and a discussion here.

• If you get to a point where you have a very large test suite (100's to 1000's of features with 100's to 1000's of step definitions…) then the typical godog structure can become a hindrance. For example because of the separation of the step function definition and the related regex (step "registration") inside the func InitializeScenario(sc *godog.ScenarioContext) {…}… there is an overhead when trying to make sense of the large code base. Once this became a problem, I have built a separate library to deal with it. This keeps the regex and the step function together, like majority of all other programming languages that do BDD have.

Hope this helps.