Imperative by day and functional by night

One Gwen Interpreter, Many Evaluation Engines

There is so much more that can be automated with Gherkin.

In the previous post, I announced the open sourcing of the gwen-interpreter project. In this post I will introduce the interpreter and evaluation engine concepts and describe the difference and relationship between them.

The Gwen interpreter translates Gherkin features into executable code. The code that each step is translated to is not defined in the interpreter itself, but rather in separate modules called evaluation engines. When a feature is executed, the interpreter delegates the processing of each step to a mixed in engine that you define or provide. This is necessary since evaluation varies across systems and it would be futile to try and code for every conceivable behavior in one implementation. For this reason Gwen abstracts the evaluation engine to support many implementations. In this way, you decide which engine to use based on the type of system you want to evaluate. For example, if you want to evaluate the behavior of a web application, then you can use our web engine. Each engine must prescribe a DSL and use at least one API to interact with a target system.


Engines can be defined to replicate any software process that is reproducible through one or more API’s.

There are many useful engines that can be built and they need not all be confined to just testing. Engines can be defined to automate, emulate, or simulate any process that is repeatable through software. Engines can also be built to generate data and other resources too.

In summary,

  • The interpreter reads Gherkin features and dispatches the processing of each step to a mixed in engine.
  • Engines define the DSL and processing to create conditions, perform actions, and assert expectations on target systems.

Hopefully many engines will emerge from the community and be shared.


Written by warpedjavaguy

May 27, 2014 at 12:17 am

Posted in automation, bdd, gherkin, scala

Tagged with

5 Responses

Subscribe to comments with RSS.

  1. Could JBehave be an evaluation engine for this? Behave must have a Gerkin like interpreter build in right?


    June 18, 2014 at 12:35 pm

    • Hi Carl,

      Gwen is an alternative to JBehave and is it’s own Gherkin interpreter. In JBehave you write POJOs to map steps and pass in a service. In Gwen you write an engine to map steps and a context to manage your service and state. The lifecycle of the context is managed by Gwen and passed to the engine at execution time.

      So you would not typically embed one interpreter in another. But you could potentially wrap a JBehave step def POJO in a Gwen engine and have Gwen delegate the processing of each step to it. To do this you would have to map each step to a method on the POJO (perhaps dynamically through a reusable adapter that introspects the JBehave annotations). It’s a level of indirection, but it would give you a REPL for free and all the other Gwen features too.


      June 18, 2014 at 3:59 pm

    • I like the idea of one set of Gerkin steps (not sure of the terminology) driving different testing engines and that seems to be at the heart of Gwen.

      Another question – would modifying Gwen be more assailable if it was written in Java or Groovy? Or do you think that being more of a framework makes this not matter as much?


      June 18, 2014 at 5:48 pm

      • Being open source, I think it does matter. Scala is both statically typed and expressive. I’m hoping that this is a win and that the community can easily get involved.


        June 18, 2014 at 8:28 pm

  2. […] workmate from a previous job posted this article discussing the release of a Gerkin (Given-When-Then) evaluation engine. Interesting idea. I figure […]

Comments are closed.

%d bloggers like this: