webship / cucumber
Cucumber Automated Functional Acceptance Testing Management system
Package info
Language:Gherkin
Type:drupal-profile
pkg:composer/webship/cucumber
Requires
- composer/installers: ~2
- drupal/core: ^11.4 || ^12
- drupal/core-composer-scaffold: ^11.4 || ^12
- drupal/cucumber_core: ^12.0.8
- drupal/cucumber_default_content: ~12.0
- drupal/cucumber_demos: ~12.0
- drupal/cucumber_recipes: ^12.0.5
- drupal/cucumber_user_roles: ^12.0.5
- drupal/uikit_admin: ~4.0
- drupal/webpatches: ~12.0
- drush/drush: ^13 || ^14
Requires (Dev)
None
Suggests
None
Provides
None
Conflicts
Replaces
None
This package is auto-updated.
Last update: 2026-10-04 16:11:29 UTC
README
A Drupal installation profile for managing automated functional acceptance testing: features written as Gherkin scripts, organised in directories, with dashboards for each team role.
Table of contents
- Features
- Requirements
- Installation
- Usage
- Testing
Features
- A "Feature" media type that stores a Gherkin script, edited with the Ace editor (Gherkin Script).
- A features page, a feature directory and default and admin dashboards (Cucumber Core).
- Optional user roles, each with its own dashboard (Cucumber User Roles).
- Products, components and projects recipes (Cucumber Recipes), and optional demo content (Cucumber Demos).
Requirements
Drupal core ^11.4 || ^12. Drupal 11.4 on PHP 8.4 is the tested default.
Every library comes from a Composer package, so no asset-packagist,
npm-asset or bower-asset repository is needed.
Cucumber depends on three contributed projects that have not reached a stable release yet:
- Display Builder —
newest release
1.0.0-beta8(beta), pulled in by Webassets. - Media Directories
and its
_ui/_editorcomponents — newest release3.0.0-rc1(rc). The stable2.0.xline only supports Drupal 8 and 9, so Cucumber Core pins^3.0@rcexplicitly. - Config Update —
newest release
2.0.0-alpha4(alpha), pulled in by Webconfig.
Composer only honours stability flags such as @beta, @rc and
@alpha in the root composer.json, so a flag written inside a
dependency is ignored. That is why the project root has to relax the
stability itself. drupal/cucumber_project already does it; if you
add Cucumber to a composer.json of your own, it needs:
{
"minimum-stability": "beta",
"prefer-stable": true,
"require": {
"drupal/config_update": "^2.0@alpha"
}
}
prefer-stable keeps every other package on its stable release: a full
Cucumber install locks 9 non-stable packages out of 186.
Installation
With the project template (recommended)
Start from the Cucumber Project template. It requires this distribution and relaxes the stability flags for you, so there is nothing else to configure. Composer, PHP, Drush and the database all run inside DDEV:
mkdir my-site && cd my-site ddev config --project-type=drupal --docroot=web ddev start ddev composer create-project drupal/cucumber_project:~12.0 ddev restart ddev drush site:install cucumber --account-name=webmaster --account-pass=<password> --site-name="<site name>" -y ddev launch
ddev restart picks up the .ddev/config.yaml the template ships (PHP 8.3,
Node.js 22, MariaDB 10.11), which replaces the one ddev config wrote. The
site is at https://<directory>.ddev.site.
On an existing DDEV project
Add the distribution to a Drupal project of your own, then install its profile:
ddev composer require webship/cucumber:~12.0 ddev drush site:install cucumber --account-name=webmaster --account-pass=<password> --site-name="<site name>" -y
The root composer.json has to relax the stability first, as described under
Requirements — otherwise Composer refuses the non-stable dependencies.
The installer asks which user roles, recipes and demo to add. The
defaults install the Admin role and all three recipes, with no demo.
To answer in a browser instead, run ddev launch and follow the installer.
Without DDEV
The same two paths work with a Composer, PHP and database stack of your own:
composer create-project drupal/cucumber_project:~12.0 my-site --no-interaction cd my-site bin/drush site:install cucumber --account-name=webmaster --account-pass=<password> --site-name="<site name>" -y
Drush lives at bin/drush, not vendor/bin/drush: the profile sets the
Composer bin-dir to bin/.
Usage
The site asks everybody to sign in: a visitor who is not signed in is
sent to /user/login, and lands on a dashboard after signing in.
Log in and create a "Feature" media item at media/add/feature: paste
or upload a Gherkin script and file it in a feature directory. The
front page is the default dashboard; features are listed at features.
A feature goes through the automated testing workflow: To Do, In
Progress, Implemented and Published, with Draft as the way back.
The Admin role and the optional user roles write features and take the steps of the workflow that fit their work. The theme of the site, front and back, is UIkit Admin: its navigation shows every signed-in person the Features, Products, Components and Projects links the role may follow, and a Log out link.
Testing
A webship-js suite (Playwright
and Cucumber-js) lives in tests/. See tests/README.md.