Cucumber a Business Readable, Domain Specific Language

Cucumber is more user story based testing framework which allows writing tests in BDD style.
It targets higher levels of abstraction. Instead of writing tests purely in code like it is done in Mocha or Jasmine, Cucumber separates tests into human-readable user stories and the code that runs them. Cucumber uses Gherkin language to write its tests. Gherkin is a Business Readable, Domain Specific Language that makes it possible to describe software’s behaviour without going in to details of how that behaviour is implemented. Since the tests are written in a plain language and anyone on the team can read them that improves communication and collaboration of the whole team.

Cucumber tests are constructed in a completely different way than a typical Mocha tests, and that construction makes them so unique. In Mocha there are wrapping clauses that nest inside of each other, mixing up test scenario description with their code implementation. Cucumber tests seem to be more ordered, they consist of feature files written in Gherkin and step definitions written in JavaScript.

Feature files have a single `Feature` description at the top and one or more `Scenarios`. `Feature` is a brief description of what is being tested and presents the justification for having the feature. It describes also the role of the user/s being served by the feature and what is expected to be done from the feature. `Scenarios` are like user stories, they do not go into details of what the software would do, they rather focus on the perspective of the person the feature is intended to serve. Each `Scenario` starts with a line that describes it and is followed by some combination of `steps` which compose the whole description of a user story.
Every `step` has its code implementation, those implementations are called step definitions.
Unlike the feature files, step definition files are not available for business people, as they are implemented in JavaScript, and can be understood only by developers. They are more like traditional test functions that one would write in Mocha or Jasmine, except they are used to match the scenarios. They handle the whole logical operations behind the `steps`, they execute them.

The division that Cucumber introduces brings a great value for the business. The Features are written in a natural language therefore business people can read them easily, give developers early feedback or even write some themselves. Another great benefit of having functional tests made with cucumber is that those tests provide a living documentation, describing how the UI interface is supposed to work for each specific feature.