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.
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.
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.