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.