Execute Gherkin scenarios in Jest
jest-cucumber is an alternative to Cucumber.js that runs on top on Jest. Instead of using describe
and it
blocks, you instead write a Jest test for each scenario, and then define Given
, When
, and Then
step definitions inside of your Jest tests. jest-cucumber then allows you to link these Jest tests to your feature files and ensure that they always stay in sync.
Jest is an excellent test runner with great features like parallel test execution, mocking, snapshots, code coverage, etc. If you're using VS Code, there's also a terrific Jest extension that allows you get realtime feedback as you're writing your tests and easily debug failing tests individually. Cucumber is a popular tool for doing Acceptance Test-Driven Development and creating business-readable executable specifications. This library aims to achieve the best of both worlds, and even run your unit tests and acceptance tests in the same test runner.
npm install jest jest-cucumber --save-dev
Feature: Logging in
Scenario: Entering a correct password
Given I have previously created a password
When I enter my password correctly
Then I should be granted access
"testMatch": [
"**/*.steps.js"
],
// logging-in.steps.js
import { defineFeature, loadFeature } from 'jest-cucumber';
const feature = loadFeature('features/LoggingIn.feature');
// logging-in.steps.js
import { defineFeature, loadFeature } from 'jest-cucumber';
const feature = loadFeature('features/LoggingIn.feature');
defineFeature(feature, test => {
test('Entering a correct password', ({ given, when, then }) => {
});
});
// logging-in.steps.js
import { loadFeature, defineFeature } from 'jest-cucumber';
import { PasswordValidator } from 'src/password-validator';
const feature = loadFeature('specs/features/basic-scenarios.feature');
defineFeature(feature, (test) => {
let passwordValidator = new PasswordValidator();
let accessGranted = false;
beforeEach(() => {
passwordValidator = new PasswordValidator();
});
test('Entering a correct password', ({ given, when, then }) => {
given('I have previously created a password', () => {
passwordValidator.setPassword('1234');
});
when('I enter my password correctly', () => {
accessGranted = passwordValidator.validatePassword('1234');
});
then('I should be granted access', () => {
expect(accessGranted).toBe(true);
});
});
});
- Asynchronous steps
- Automatic step Binding
- Backgrounds
- Configuration options
- Contributing
- Gherkin tables
- Re-using step definitions
- Running the examples
- Running with another test runner
- Scenario outlines
- Step definition arguments
- Using Docstrings
If you prefer an experience more like Cucumber with global step matching and the ability to define steps exactly once that can be matched to multiple steps across multiple feature files, then Jest Cucumber does accommodate this preference with autoBindSteps.
However, the default mode in Jest Cucumber can be thought of as Cucumber reimagined for Jest, and is designed for writing Jest tests that are kept in sync with Gherkin feature files. The goal is that your Jest tests (i.e., step definitions) are perfectly readable by themselves without jumping back and forth between step definitions and feature files. Another goal is to avoid global step matching, which many people find problematic and difficult to maintain as a codebase grows. By default, Jest Cucumber expects that your step definitions and feature files match exactly, and will report errors / generate suggested code when they are out of sync. To avoid duplicated step code, you can use the techniques described here.