Rename to cucumber-backend?

[aslakhellesoy]

I find the name pickle runner a little misleading. It suggests that it runs pickles, which it doesn't. The pickles run in the language frontend. The pickle-runner only tells the frontend to run it.

[aslakhellesoy]

@charlierudolph I'm about to start writing out a roadmap for Cucumber that I will publish on the blog. I'd like to refer to this project as "Cucumber Backend". Any objections?

[mpkorstanje]

We already have $language-backends in cucumber-jvm. Adding a cucumber-backend would make things a bit confusing. For example the cucumber-backend is the backend to cucumber-jvm but the cucumber-backend would be the frontend to the java-backend in cucumber-jvm .

I am also under the impression the pickle-runner "defers running the hooks / steps to the caller" rather then deferring whole pickles. With this in mind it is a subsystem of a specific kind of runner.

Maybe it would help to sketch out some context around these components?

[aslakhellesoy]

This is how I think of it (in thew future)

[ Front-end ]<---protobuf--->[ Back-end (Go) ]

Without going into the details of the protobuf message protocol, let's look at what happens where:

The Front-end does the following things:

• Start a "run" by sending some configuration to the backend
• Do what the backend tells it to do
  • Run parameter type and data table transformers
  • Run step defs and hooks
• Send results to backend

The Back-end does the following things:

• Read .feature files and compile them into GherkinDocument AST objects and Pickle objects
• Match steps to Cucumber Expressions
• Tell the front-end what to do
• Write out reports

What we currently call "backend" in Cucumber-JVM can be renamed to "programming language adapter" or something.

I think of the back-end more as an orchestrator. It does the language-independent things, and tells the front-end what to do, then collect the results.

[mpkorstanje]

My mental model looks like this:

             |  -- creates ---------------> [plugins]
             |                                    | 
             |                                    | Events
             |                                    |
[cucumber-jvm]  -- starts ----------------> [cucumber-server]
             |                                    |
             |                                    | Commands/Results
             |                                    |
             | -- creates and assigns --->  [workers] -- operate on --> [testcontext]

So perhaps we can we use worker/executor and server metaphors instead? It doesn't have the presentation/customer facing semantics that bother me ( frontend starting and owning a backend feels off).

[mattwynne]

I don't love "backend", it doesn't give me any clues about what it's responsibilities are.

I hear you about "runner", though in practice nothing will run without this thing, so I'd prefer that over "backend".

I agree with @mpkorstanje that we need to think about a metaphor to help with the name. I don't have any good ideas yet but I'll give it some more thought.

[mattwynne]

Thinking out loud about a metaphor (not a confident suggestion, just something to trigger thoughts) this thing is like the hub or gears of a bicycle wheel, with the language-specific front-ends being the tyres that connect the whole wheel to the road (your app).

@tooky you like metaphor - any thoughts?

[mpkorstanje]

Just doing some create assosiations pickle-jar? Cucumber-batch? Refigirator?

[mattwynne]

Slicer? Muncher?

[mpkorstanje]

Cucumber Kitchen? Sous-chef?

[mpkorstanje]

pickle-deamon?

[aslakhellesoy]

Kernel - or Core?

It doesn't run pickles, it creates them, matches them to stepdefs, tells the frontend (for lack of a better word) to run the step definitions and collects their results. Then it generates reports.

It pretty much does everything except for running the pickles and providing a platform-specific way to define and run step definitions.

It's almost like an engine. It encapsulates the complicated parts we don't want to see (blending petrol with oxygen and setting it on fire == reading and matching stepdefs), (combustion chamber == running stepdefs), revolving an axis that is connected to external components (outputting rotation => turning wheels == outputting results => generating results). So formatters are really consumers of the output generated by the engine.

Cucumber Engine?

[mattwynne]

Choo choo!

It doesn't just collect the results. It also has the logic for deciding whether to carry on running steps on a scenario or skip them, depending on the status of the last one.

[mpkorstanje]

I think engine is a good way to describe this generic collection services. Just hook up the fuel tank, water line and some wheels.

[charlierudolph]

I like engine.

[mattwynne]

I like engine too.

Ha ha though when I think about the metaphor of Cucumbers, I can't help suggesting "belly"! What does that make the results that come out the other end though? 💩

[mattwynne]

Being a Dad doesn't do a lot for your jokes, sorry 😜

[aslakhellesoy]

Renamed: https://github.com/cucumber/cucumber-engine

[mattwynne]

Now I see it for real it makes me want to give it a logo like https://depositphotos.com/57776219/stock-photo-cucumber-train.html