Cucumber-style code generator from feature files

[ashleyfrieze]

The GherkinSyntax capability of Spectrum makes it a substitute for

• runtime parsing of feature files
• "glue code" which binds the Gherkin syntax to runtime code

In Spectrum, both of the above are expressed in the initialisation of a test class in a single place.

In CucumberJVM, the "glue code" (e.g. @Given("there are cukes") public void there_are_cukes() {}) is not hand-written, it's generated. This is how you bind code to the feature files and this is how it's easy for testers or BA's to update feature files and for them to be used in tests.

While Spectrum can in a lot of situations be simply easier and neater than using Cucumber, there's one big difference in the process. With Spectrum as it stands a developer has to manually convert a Gherkin spec into the Java code and if the tester/BA were to change the original Spec, nobody would necessarily notice and it would be a manual conversion if they were.

Proposal: provide a means of scanning a source of .feature files and mapping them to the respective test classes and spec definitions within those classes in Spectrum. This would allow:

• start with feature file and generate skeleton of test
• scan that the tests match the feature files
• provide diffs between tests and feature files, proposing the code change to put the skeleton in

In Cucumber, this check runs before every test, and can be set to make the test fail, or just be a warning. The output of cucumber might be:

Missing steps. Try adding:

@Given("there is a cuke")
public void there_is_a_cuke() {
    throws new PendingException();
}

We could do something similar in Spectrum. There could be a feature file scanner which might output:

Warning: missing test class for feature file "MyFeature.feature" with:

    Feature: My feature
    Scenario: My scenario

    Given a cuke
    When eat cukes
    Then no cukes

Try adding:

@RunWith(Spectrum.class)
public class MyFeature {{
    feature("My feature", () -> {
        scenario("My scenario", () -> {
            given("a cuke", () -> {
                pending();
            });
            when("eat", () -> {
                pending();
            });
            then("no cukes", () -> {
                pending();
            });
        });
    });
}}

Or maybe it could output diffs

Warning class "SomeFeatureTest" has extra:

    feature("some deleted feature" ...)

I think this would not be difficult to produce, and would make Spectrum a serious contender for a CucumberJVM replacement.

[greghaskins]

Very interesting idea. Can you describe more detail about the workflow the Cucumber provides, for those of us who don't use it often? For example, what's the flow when adding a new feature to the system? (Create a .feature file?, then run program X?, then .... ?)

[ashleyfrieze]

In Cucumber you normally:

• Write a feature file
  • This might re-use the text of existing test steps you'd written previously and that's part of the idea of Cucumber, to build a specification language
  • It might contain new Given, When or Then descriptions
• Execute the test (with either fail on pending or not)
  • Any pending steps - i.e. ones which have no glue code implementation for the Gherkin steps mentioned - will be flagged
  • For each pending step, the skeleton of the glue code is output to the console for you to paste into your step definitions classes
• When you define a step, you annotate a function in a glue code class to match what's in feature files, then you make that function execute the step
  • Functions can be parameterless, or can take values or objects implied by the text of the step
  • Where there are values in the text, these need to be selected for by regexes in the @Given/@When etc annotation on the function
  • Cucumber will assemble pojos from multiple values if you wish - it can also assemble tables
• After each round of test definition (feature file modification) and glue code construction, you re-run the tests to see what's now working/not/missing