Ginkgo does not strictly follow Gherkin notation but, since the narrative for tests is a free form text nothing stops you from typing what you want there. You could also create your own functions in place of Describe, Context, It, Specify to make it look like familiar Given, When and Then.
Gomega’s fluidish interface for assertions feels complete enough but a bit poorer than Java’s Hamcrest which offers matcher for pretty much any corner case. I am convinced it is just a matter of time though, as you are free to create custom matchers.
Cucumber uses plain English feature files and separate Step files, while Ginkgo keeps everything as code. That feature could have an impact on teams where non-technical staff maintains the BDD statements. In Ginkgo these members would need to understand a tiny bit more about the syntax. I don’t know of such cases from autopsy though, so maybe it is not an issue after all. Also, even in Cucumber’s plain English feature files, it benefits everybody greatly to demonstrate the understanding of the system to construct these statements in a meaningful manner. Otherwise you will have a hard time mapping “steps” onto routines.
Following are two examples of my BDD style test files using Ginkgo and Gomega. It is by no means a reference of how it should be done, just a way I did it to help solidify and document requirements on this particular project.
The example files are using Describe for standard tests, DescribeTable for parametrised tests and Measure for performance test.
This small project is available at GitHub.