Consider cucumber-java-lambda as a replacement for cucumber-java8

[mpkorstanje]

cucumber-java8 allows step definitions to be defined as lambda's. This is really nice because it removes the need to type your step definition twice as you would with cucumber-java. So there is a good reason to use lambda's to define step definitions.

Compare:

Given("A gherkin and a zukini", () -> { 

});

@Given("A gherkin and a zukini")
public void a_gherkin_and_zukini(){

}

Unfortunately with cucumber-java8 lambda's must be defined in the constructor of a step definition class. As a result we can not know which step definitions are defined until a Cucumber scenario has started and all world objects are instantiated. This makes it impossible to discover, cache and validate step definitions up front, preventing us from making Cucumber more efficient (#2035).

public class StepDefinitions {
     public StepDefinitions(){
        Given("A gherkin and a zukini", () -> { 

       });
     }
}

Additionally Cucumber uses typetools to determine the type of lambda parameters. This requires the use of of Unsafe to fish in the constant pool. This is a non-trivial process and Cucumber currently uses typetools to facilitate this. However because this fundamentally depends on unsafe operation it is not guaranteed to work in the long run.

Requested solution

1. Implement cucumber-lambda as an alternative for cucumber-java8 that uses a DSL to build step definitions. Because this DSL is created in a static field it can be discovered in the same way cuucmber-java discovers step definitions and avoids the issues of cucumber-java8.

public class CucumberLambdaStepDefinitions {

    @Glue
    public static CucumberLambda glue = CucumberLambda
        .using(World.class)
        .step("A gherkin and a zukini", (World world) -> () -> { 
             world.setGherkins(1);
             world.setZukinis(1);
        })
        .step("{int} gherkin(s) and {int} zukini(s)", (World world) -> (int gherkins, int zukinis) -> {
             world.setGherkins(gherkins);
             world.setZukinis(zukinis);
        });

       // repeat for hooks, parameter types and data table types, ect
       // hooks should be named beforeAll, beforeEach, beforeStep.

2. Avoid the use of typetools where possible by specifying all parameter types

3. The World object is created using DI as usual. Consider the possibility of defining steps/hooks using multiple objects.

CucumberLambda
    .using(GherkinPatch.class, ZukiniPatch.class)
    .step("A gherkin and a zukini", (gherkinPatch, zukiniPatch) -> () -> { 
        // tend to the vegetable garden here
    });

Out of scope

4. Generate localized vairations of the DSL that use Given/When/Then.

    @Glue
    public static CucumberLambda glue = io.cucumber.lambda.en.CucumberLambda
        .using(World.class)
        .given("A gherkin and a zukini", (World world) -> () -> { 
             world.setGherkins(1);
             world.setZukinis(1);
        })
        .when("{int} gherkin(s) and {int} zukini(s)", (World world) -> (int gherkins, int zukinis) -> {
             world.setGherkins(gherkins);
             world.setZukinis(zukinis);
        });
        // ect.

[laeubi]

I must confess I always found the annotation method more powerful, readable and easy to use. Its also easier for tools to handle them and give good advice. Code is written once but read hundreds of times and I never have found it a burden to "type twice" (better read as: Think twice :-)

Especially the more advanced one I hardly see any "easier typing" but chances for people getting crazy getting all this ()-> {} -> (...) right 👎

[aslakhellesoy]

I agree with @laeubi - I always preferred the annotation style. At the time when we wrote the lambda API, lambdas were relatively new in Java, and I think the main driver was novelty.

I love lambdas for functional programming, but step definitions feel more "procedural" to me, which is probably why I never used them myself.

That said, I think the API you've proposed looks really nice. Maybe we should gauge the interest in the community with a survey? I'd like to understand more about what people want. If people prefer lambdas, what are the main reasons?

[mpkorstanje]

Looking at the monthly stats I think there is already sufficient interest in lambda's:

io.cucumber:cucumber-core:   800k downloads
io.cucumber:cucumber-java:   700k downloads
io.cucumber:cucumber-junit:  600k downloads
io.cucumber:cucumber-spring: 200k downloads
io.cucumber:cucumber-java8:  160k downloads
io.cucumber:cucumber-testng: 160k downloads
io.cucumber:cucumber-pico:   140k downloads
io.cucumber:cucumber-guice:   20k downloads

--

One of the interesting things is also that less then half the users do not use dependency injection. This means that information is shared between steps using static variables. This is somewhat understandable because when using annotations you would either have to put all step definitions in one file, use dependency injection or use static variables.

The use of static variables is most undesirable as it makes it likely that tests influence and each other and makes parallel execution of tests impossible. However the solution, dependency injection, has a significant conceptual on ramp. This means that many users of Cucumber who don't have a significant experience in software engineering concepts will not know about this. Furthermore the concept is also hidden, making discovery impossible.

This is quite unlike the other Cucumber implementations where the shared context (world) is an explicit concept. And in other Cucumber implementations this shared context can be used even without dependency injection. By using a DSL which makes the shared context (world) explicit it would be possible for users to organize their step definitions in different files and share information between steps without using dependency injection. This should provide a better way to keep tests clean and smooth the on-ramp to both parallel execution and dependency injection significantly.

--

Compared to annotations a DSL with lambdas does solve another problem. When using annotations without dependency injection steps can only access the class in which they are defined. This puts constraints on the organizations of step definitions.

For example suppose we have a process that involves composting some vegetables with the aid of cow manure and dung beetles. We could organize these steps around the components they interact with along with other steps that interact with the same components.

public class VegtablePatchStepDefinitions { 
    private final VegtablePatch vegtablePatch;

    @Given("A gherkin and a zukini")
    public void a_gherkin_and_zukini(){
         // can only access members of VegtablePatchStepDefinitions directly
    }
}
public class CompostStepDefinitions { 
 
    private final CompostHeap heap;
    private final DungBeetleBreeder dungBeetleBreeder;
    private final Cows cows;

    @Given("A hand full of dung beetles")
    public void a_hand_full_of_dung_beetles(){
         // can only access members of CompostStepDefinitions directly
    }
}

Or we could organize them thematically with a lot less ceremony:

public class CreatingVegtableCompost {

    @Glue
    public static CucumberLambda glue = CucumberLambda
        .using(VegtablePatch.class)
        .step("A gherkin and a zukini", (vegtablePatch) -> () -> { 
             
        })
        .using(CompostHeap.class, DungBeetleBreeder.class, Cows.class)
        .step("A hand full of dung beetles", (compostHeap, dungBeetleBreeder, cows) -> () -> {

        });
}

[rmannibucau]

@mpkorstanje think the stats are biased because libs integrate with core and not spring/cdi/whatever framework in general. For example, cukespace will provide IoC on all env without using cucumber-cdi but using core and java8 (for lambda support).
If CucumberLambda can be "not" static then it would enable to rely on injections properly (and therefore state). It was a blocker we needed to workaround in cukespace for lambda support adding a "init" lifecycle for the lambdas.

[mpkorstanje]

@mpkorstanje think the stats are biased because libs integrate with core and not spring/cdi/whatever framework in general.

If 50% of all cucumber users were using some DI container that wasn't provided by Cucumber I think we would have known a few of them.

If CucumberLambda can be "not" static then it would enable to rely on injections properly (and therefore state). It was a blocker we needed to workaround in cukespace for lambda support adding a "init" lifecycle for the lambdas.

The definition must be static. Otherwise steps can not be discovered without instantiating the test execution context (world, dependency injection context, ect). If this is confusing and does not seem like a solution, compare this to cucumber-java where all step definitions are static and no init hacks are needed.

To further clarify, this part of the DSL handles the registration of the step definition:

 .when("{int} gherkin(s) and {int} zukini(s)", ...

Then this part of DSL is executed only when the step is executed.

 (World world) -> (int gherkins, int zukinis) -> {
             world.setGherkins(gherkins);
             world.setZukinis(zukinis);
        }

Overly simplified a step definition would executed like so:

Function<World, Function<Integer, Integer>> stepDefinitionBody  =  (world) -> (gherkins, zukinis) -> {
             world.setGherkins(gherkins);
             world.setZukinis(zukinis);
}
stepDefinitionBody.apply(lookup.get(World.class)).apply(12, 12);

As you can see, unlike cucumber-java8 the world does only has to be instantiated to execute the step definition exactly because they are static.

[rmannibucau]

The definition must be static. Otherwise steps can not be discovered without instantiating the test execution context (world, dependency injection context, ect). If this is confusing and does not seem like a solution, compare this to cucumber-java where all step definitions are static and no init hacks are needed.

This can be made compatible while the lambda gets access to the instance/context somehow but it fully defeats the concept to define them as field since it makes it all defined in static which requires the impl to do a lazy lookup.
I prefer the option to force the lambda def to be instantiated to be registered - this part is fine - but not injection aware at definition time and injection aware at step execution time only - thanks lambdas it works. Sounds like the least worse compromise for end users to me.

[mpkorstanje]

I don't understand a word of what you are saying.

[rmannibucau]

@mpkorstanje if you can't use injection it is generally pointless and prevents any evolution of cucumber setup (you are stucked to plain java). I think it is a bad thing so we must enable to use IoC since with suite complexity it eases things a lot.

Two options I see are:

1. force a first param to be the world/context (nice but not fluent and close to the forced lookup solution)
2. enable to use injections:
   2.a. public interface LambdaDef { void define(); } - https://github.com/cukespace/cukespace/blob/master/core/src/main/java/cucumber/runtime/arquillian/api/Lambda.java. You implement that to define a lambda, cucumber instantiate it and calls define to register the lambdas. At that stage injections are NOT available but lambdas can use it (resolved lazily by design).
   2.b. cucumber injects the LambdaDef impl enabling to use injections in the lambdas (https://github.com/cukespace/cukespace/blob/master/examples/src/test/java/cucumber/runtime/arquillian/java8/J8Test.java).

Indeed I prefer 2 which proved working well and stick to well known pattern rather than forcing users to write code through a new way and create helpers to solve this lookup+storage point.

[laeubi]

This is quite unlike the other Cucumber implementations where the shared context (world) is an explicit concept. And in other Cucumber implementations this shared context can be used even without dependency injection.

That's why I have suggested #1713 in the past. I don't see how lamdas can help here much. Even a super simple DI mechanism that only allows to inject other Glues via a setter like this

@Inject
public void setMyOtherGlue(GlueCode other) {

}

would be more profitable from my point of view than all these lambda stuff.

[rmannibucau]

@laeubi DI is supported already with multiple IoC (from the plain jsr330 to the full 299 or more recent ones), just bring the underlying needed impl to get it. Lambda is really nice because it does not require to spread accross multiple method the state.

The very nice pattern I saw is something along:

final var state = new MyState();
Given(...., (xxx) -> state.reset(xxx));
When(..., (x) -> state.doX(x));
// ...

It enables to have properly scoped variables for steps known in the same "bucket" (like auth or things like that).
Mixed with IoC it is a very very fluent way to write steps.

[laeubi]

@rmannibucau of course its possible to maybe write your own Lamda Impl for cucumber as well... the point is, that at least one plain injection mechanism should be supported by cucumber-core so there is no need to add one extra.

For lamdas iteself, its fine for simple glues, but as they get more complex the lamdas get more and more confusing and as stated above its very hard to have good IDE support for them (as the IDE can hardly guess that a string is not a string but a parameter that forms a step).

[rmannibucau]

@laeubi Not really, I'm not sure I get the point for cucumber-core to reimplement jsr330? there are tons of impls out there only supporting it (ie no more than jsr330) so I'm not sure it is needed - will not enable a single use case to end users is the point I want to highlight.
About your point about the IDE tooling, it is only harder when the matcher is not a constant string - in all other cases it is 1-1 with annotations and as hard to support than annotations.
These cases are rare and when they would be it just means the user will not get completeness of its steps/validation through the IDE which is not something highly used AFAIK so I think it is not a blocker anyway.
The big plus of lambdas is to enable decoration and composition by design (fn) whereas to do it on steps is sometimes hard - depends the IoC you use but with IoC not using lazy instantiation and supporting interception OOTB, ie the most common ones, it is very hard to do.