Executing a specific ginkgo test from a godog step

[hh]

I'm exploring adding Gherkin support for kubernetes to separately define our behaviours/features from our tests.

We currently make heavy use of Ginkgo, and much of our infrastructure is based on it.

I'd like create a set of .features referencing our existing tests, while allowing us to make use of Feature:, Scenario:, and tagging via Gherkin. It would help projects like ours that already use ginkgo, but would like to benefit from separating BDD files from the implementations.

Feature: Use existing ginkgo framework
  As a test contributor
  I want to not throw away all our old tests
  In order to retain the value generated in them
  @ginko @k8s.io @Conformance @NodeConformance
  Scenario: Container Lifecycle Hook when create a pod with lifecycle hook should execute poststart exec hook properly
    Given existing test "[k8s.io] Container Lifecycle Hook when create a pod with lifecycle hook should execute poststart exec hook properly [NodeConformance] [Conformance]"
    When I run the test
    Then the existing test will pass
    And this is fine
  @ginko @k8s.io @NodeConformance
  Scenario: Container Runtime blackbox test when running a container with a new image should be able to pull from private registry with secret
    Given existing test "[k8s.io] Container Runtime blackbox test when running a container with a new image should be able to pull from private registry with secret [NodeConformance]"
    When I run the test
    Then the existing test will pass
    And this is fine

I'm exploring this via kubernetes/kubernetes#79914

[hh]

https://github.com/kubernetes/kubernetes/pull/79914/files#r302236077 is focused on the step function that has the existing ginkgo test string.

It's a bit of a cross-post, but I also opened an issue with gingko, to see if there is a way we can tie the frameworks together in this way. onsi/ginkgo#588

[l3pp4rd]

Hi, it is pleasant to see the adoption of cucumber in go user space. Now concerning the integration with ginkgo, as far as I can see, only two options pop up:

1. If it is possible to access ginkgo functions for single specific behavior description with all the context functions wrapped around it. Then calling it from a godog step definition might only require some tricks to determine the failure and return it as an error
2. If ginkgo provides cli options to invoke si gle scenario, godog step definition could call it with exec.Command though you may need to pass env vars in order to prevent booting something expensive all over in each of the step calls. Then slowly steps can be migrated.

If none of those options are reasonable, then probably you could consider godog for new packages only. Also maybe using too many testing frameworks in one project, might make it harder to cope with for contributors