WordPress.org
Get WordPress
WordPress.org

WordPress Developer Resources

wp scaffold package-tests

wp scaffold package-tests

Generate files for writing Behat tests for your command.

In this article

Back to top

GitHub
View Open Issues (3) View Closed Issues (49) Create New Issue
This command runs on the before_wp_load hook, just before the WP load process begins. WP-CLI makes use of a Behat-based testing framework, which you should use too. This command generates all of the files you need. Functional tests are an integral ingredient of high-quality, maintainable commands. Behat is a great choice as a testing framework because:
  • It’s easy to write new tests, which means they’ll actually get written.
  • The tests interface with your command in the same manner as your users interface with your command, and they describe how the command is expected to work in human-readable terms.
Behat tests live in the features/ directory of your project. When you use this command, it will generate a default test that looks like this: 
Feature: Test that WP-CLI loads.

  Scenario: WP-CLI loads for your tests
    Given a WP install

    When I run `wp eval 'echo "Hello world.";'`
    Then STDOUT should contain:
      """
      Hello world.
      """
Functional tests typically follow this pattern:
  • Given some background,
  • When a user performs a specific action,
  • Then the end result should be X (and Y and Z).
View all defined Behat steps available for use with behat -dl: 
Given /^an empty directory$/
Given /^an empty cache/
Given /^an? ([^\s]+) file:$/
Given /^"([^"]+)" replaced with "([^"]+)" in the ([^\s]+) file$/
The files generated by this command include:
  • .travis.yml is the configuration file for Travis CI.
  • bin/install-package-tests.sh will configure your environment to run the tests.
  • bin/test.sh is a test runner that respects contextual Behat tags.
  • features/load-wp-cli.feature is a basic test to confirm WP-CLI can load.
  • features/bootstrap, features/steps, features/extra are Behat configuration files.
After running bin/install-package-tests.sh, you can run the tests with ./vendor/bin/behat. If you find yourself using Behat on a number of projects and don’t want to install a copy with each one, you can composer global require behat/behat to install Behat globally on your machine. Make sure ~/.composer/vendor/bin has also been added to your $PATH. Once you’ve done so, you can run the tests for a project by calling behat. For Travis CI, specially-named files in the package directory can be used to modify the generated .travis.yml, where <tag> is one of ‘cache’, ‘env’, ‘matrix’, ‘before_install’, ‘install’, ‘before_script’, ‘script’: * travis-<tag>.yml – contents used for <tag>: (if present following ignored) * travis-<tag>-append.yml – contents appended to generated <tag>: You can also append to the generated .travis.yml with the file: * travis-append.yml – contents appended to generated .travis.yml

Environment

The features/bootstrap/FeatureContext.php file expects the WP_CLI_BIN_DIR environment variable. WP-CLI Behat framework uses Behat ~2.5, which is installed with Composer.

Installing

Use the wp scaffold package-tests command by installing the command’s package:

wp package install wp-cli/scaffold-package-command

Once the package is successfully installed, the wp scaffold package-tests command will appear in the list of available commands.

Options

<dir>
Directory path to an existing package to generate tests for.
[--ci=<provider>]
Create a configuration file for a specific CI provider.
—
default: travis
options:
– travis
– circle
– github
—
[--force]
Overwrite files that already exist.

Examples

# Generate files for writing Behat tests.
$ wp scaffold package-tests /path/to/command/dir/
Success: Created package test files.

Global Parameters

These global parameters have the same behavior across all commands and affect how WP-CLI interacts with WordPress.
Argument Description
--path=<path> Path to the WordPress files.
--url=<url> Pretend request came from given URL. In multisite, this argument is how the target site is specified.
--ssh=[<scheme>:][<user>@]<host\|container>[:<port>][<path>] Perform operation against a remote server over SSH (or a container using scheme of “docker”, “docker-compose”, “docker-compose-run”, “vagrant”).
--http=<http> Perform operation against a remote WordPress installation over HTTP.
--user=<id\|login\|email> Set the WordPress user.
--skip-plugins[=<plugins>] Skip loading all plugins, or a comma-separated list of plugins. Note: mu-plugins are still loaded.
--skip-themes[=<themes>] Skip loading all themes, or a comma-separated list of themes.
--skip-packages Skip loading all installed packages.
--require=<path> Load PHP file before running the command (may be used more than once).
--exec=<php-code> Execute PHP code before running the command (may be used more than once).
--context=<context> Load WordPress in a given context.
--[no-]color Whether to colorize the output.
--debug[=<group>] Show all PHP errors and add verbosity to WP-CLI output. Built-in groups include: bootstrap, commandfactory, and help.
--prompt[=<assoc>] Prompt the user to enter values for all command arguments, or a subset specified as comma-separated values.
--quiet Suppress informational messages.

Command documentation is regenerated at every release. To add or update an example, please submit a pull request against the corresponding part of the codebase.