-
·
Then /^the return code should( not)? be (d+)$/
Expect a specific exit code of the previous command. Usage Scenario: My example scenario Given a WP installation When I try `wp plugin install` Then the return code should be 1 Behat steps documentation is generated from the WP-CLI codebase on every release. To suggest improvements, please submit a pull request. Related Then /^(STDOUT|STDERR) should(…
-
·
When /^I launch in the background `([^`]+)`$/
Launch a given command in the background. Usage Scenario: My example scenario Given a WP install And I launch in the background `wp server –host=localhost –port=8181` … Behat steps documentation is generated from the WP-CLI codebase on every release. To suggest improvements, please submit a pull request. Related When /^I (run|try) `([^`]+)`$/ – Run or…
-
·
When /^I (run|try) `([^`]+)` from ‘([^s]+)’$/
Run or try a given command in a subdirectory. Usage run expects an exit code 0, whereas try allows for non-zero exit codes. Scenario: My example scenario When I run `wp core is-installed` Then STDOUT should be empty When I run `wp core is-installed` from ‘foo/wp-content’ Then STDOUT should be empty Behat steps documentation is…
-
·
When /^I (run|try) the previous command again$/
Run or try the previous command again. Usage run expects an exit code 0, whereas try allows for non-zero exit codes. Scenario: My example scenario When I run `wp site option update admin_user_id 1` Then STDOUT should contain: “”” Success: Updated ‘admin_user_id’ site option. “”” When I run the previous command again Then STDOUT should…
-
·
When /^I (run|try) `([^`]+)`$/
Run or try a given command. Usage run expects an exit code 0, whereas try allows for non-zero exit codes. So if using run and the command errors, the step will fail. Scenario: My example scenario When I run `wp core version` Then STDOUT should contain: “”” 6.8 “”” Scenario: My other scenario When I…
-
·
Then /^STDOUT should be CSV containing:$/
Expect STDOUT to be CSV containing certain values. Usage Scenario: My example scenario When I run `wp term list post_tag –fields=name,slug –format=csv` Then STDOUT should be CSV containing: | name | slug | | Test term | test | Behat steps documentation is generated from the WP-CLI codebase on every release. To suggest improvements, please…
-
·
Then /^STDOUT should be JSON containing:$/
Expect valid JSON output in STDOUT. Usage Scenario: My example scenario When I run `wp post meta get 1 meta-key –format=json` Then STDOUT should be JSON containing: “”” { “foo”: “baz” } “”” Behat steps documentation is generated from the WP-CLI codebase on every release. To suggest improvements, please submit a pull request. Related Then…
-
·
Then /^STDOUT should be YAML containing:$/
Expect STDOUT to be YAML containing certain content. Usage Scenario: My example scenario When I run `wp cli alias list` Then STDOUT should be YAML containing: “”” @all: Run command against every registered alias. @foo: path: {TEST_DIR}/foo “”” Behat steps documentation is generated from the WP-CLI codebase on every release. To suggest improvements, please submit…
-
·
Then /^STDOUT should end with a table containing rows:$/
Expect STDOUT to end with a table containing the given rows. Usage Useful when the table is preceded by some other output. Scenario: My example scenario Given a WP installation When I run `wp search-replace foo bar –report-changed-only` Then STDOUT should contain: “”” Success: Made 3 replacements. “”” And STDOUT should end with a table…
-
·
Then /^(STDOUT|STDERR) should be a number$/
Expect STDOUT or STDERR to be a numeric value. Usage Scenario: My example scenario Given a WP installation When I run `wp db size –size_format=b` Then STDOUT should be a number Behat steps documentation is generated from the WP-CLI codebase on every release. To suggest improvements, please submit a pull request. Related Then /^the return…