Declare and check the external tools that scenarios need
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 45/100
Research direction
Start from the Behat feature files config-edit.feature and post.feature and the requirement handling described in #392. Read the test runner that filters on @require-* tags and the linter for feature files. Done means required executables are declared as tags, checked before run, and missing tools report as undeclared with the tag to add.
Written by the indexing model from the issue text.
Description
Some scenarios depend on external tools without declaring it. For example, config-edit.feature in config-command and post.feature in entity-command use ex as the editor. Where ex is missing, these scenarios fail halfway through, after the setup has already run. In post.feature that happens at the 17th step of the scenario, after a WordPress install and 6 wp calls.
Some declared requirements are not checked at all: @require-composer, @require-download and @require-opcache-save-comments appear in feature files but never filter anything.
Steps:
- Support declaring required executables as tags, checked before the run like the other requirements and reported as described in #392.
- Check the existing
@require-*tags that are currently ignored, and warn about unknown ones so that typos do not go unnoticed. - When a command fails because an executable is missing, report it as an undeclared requirement, naming the tag to add, instead of as a regular test failure. This also catches tools used inside
wpcommands, such asmysqldump,svnorzip. - Flag steps that call known external tools without the matching tag when the feature files are linted.
- Add the missing tags to the existing feature files in the command packages.
- Dominant language
- PHP
- Stars
- 42
- Forks
- 28
- Avg merge
- 15h 17m
- Merged PRs (30d)
- 6
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from wp-cli/wp-cli-tests
-
scope:testing status:unconfirmed
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
wp-cli/wp-cli-tests#389 · 1 comment ·
Maintainers usually reply within 1 day
-
scope:testing
Difficulty 5/5 Over a week Newbie friendliness 20/100
wp-cli/wp-cli-tests#395 ·
Maintainers usually reply within 1 day
-
scope:testing
Difficulty 4/5 3-5 days Newbie friendliness 30/100
wp-cli/wp-cli-tests#394 ·
Maintainers usually reply within 1 day
-
scope:testing
Difficulty 3/5 1-2 days Newbie friendliness 70/100
wp-cli/wp-cli-tests#392 ·
Maintainers usually reply within 1 day
-
scope:testing status:unconfirmed
Difficulty 4/5 3-5 days Newbie friendliness 45/100
wp-cli/wp-cli-tests#391 · 1 comment ·
Maintainers usually reply within 1 day
All issues in wp-cli/wp-cli-tests
Similar issues
-
bug webbackend
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
DOMjudge/domjudge#3886 · 1 comment ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
opensourcepos/opensourcepos#4794 ·
Maintainers usually reply within 1 day
-
repo:cms
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
craftcms/cms#20235 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
Maintainers usually reply within 1 day
-
REST API: decimal ids like 1.5 give 500 on folder and report endpointsPossibly taken @console-log-life claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
Maintainers usually reply within 3 days