Setup & teardown hardening

[swissspidy]

No description provided.

[github-actions]

Hello! 👋

Thanks for opening this pull request! Please check out our contributing guidelines. We appreciate you taking the initiative to contribute to this project.

Contributing isn't limited to just code. We encourage you to contribute in the way that best fits your abilities, by writing tutorials, giving a demo at your local meetup, helping other users with their support questions, or revising our documentation.

Here are some useful Composer commands to get you started:

• composer install: Install dependencies.
• composer test: Run the full test suite.
• composer phpcs: Check for code style violations.
• composer phpcbf: Automatically fix code style violations.
• composer phpunit: Run unit tests.
• composer behat: Run behavior-driven tests.

To run a single Behat test, you can use the following command:

# Run all tests in a single file
composer behat features/some-feature.feature

# Run only a specific scenario (where 123 is the line number of the "Scenario:" title)
composer behat features/some-feature.feature:123

You can find a list of all available Behat steps in our handbook.

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request enhances the robustness of the test suite's setup and teardown processes. It streamlines automated test execution by pre-configuring a prompt-skipping environment variable and refines the post-test cleanup logic to ensure temporary test directories are reliably removed, especially within continuous integration pipelines.

Highlights

• Test Environment Configuration: Introduced the WP_CLI_SKIP_PROMPT environment variable with a value of 'no' to prevent interactive prompts during automated tests, ensuring smoother execution.
• Test Teardown Logic: Modified the afterScenario hook to conditionally remove the test run directory. The directory is now removed even if there's an error, specifically when running in a CI environment and not in debug mode, to prevent orphaned directories.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[codecov]

Codecov Report

❌ Patch coverage is 0% with 9 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/Context/FeatureContext.php	0.00%	9 Missing ⚠️

📢 Thoughts on this report? Let us know!

[gemini-code-assist]

Code Review

This pull request aims to harden the test setup and teardown processes. The changes introduce an environment variable to manage prompts and refine the cleanup logic for CI environments. While the direction is good, there are a couple of areas that could be improved for clarity and robustness. Specifically, the value used for WP_CLI_SKIP_PROMPT is counter-intuitive, and the method for evaluating boolean environment variables could be more reliable. I've provided specific suggestions in the comments to address these points.

[Copilot]

Pull request overview

Hardens the Behat test harness setup/teardown behavior in FeatureContext by adjusting process environment defaults and cleaning up the scenario RUN_DIR more aggressively under CI.

Changes:

• Adds WP_CLI_SKIP_PROMPT to the environment passed to spawned wp processes.
• Updates @AfterScenario cleanup logic to remove the altered WP install on CI even when scenarios fail.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

$is_debug here is effectively never truthy during normal test runs because prepare() exits early when WP_CLI_TEST_DEBUG_BEHAT_ENV is set (FeatureContext.php:697-699). That makes the ! $is_debug part misleading/dead in practice. Either remove the debug branch, or change the debug behavior so the suite can run while preserving RUN_DIR for inspection when WP_CLI_TEST_DEBUG_BEHAT_ENV is enabled.

Suggested change

	$is_ci = getenv( 'CI' );
	$is_debug = getenv( 'WP_CLI_TEST_DEBUG_BEHAT_ENV' );
	if ( $scope->getTestResult()->getResultCode() <= 10 || ( $is_ci && ! $is_debug ) ) {
	$is_ci = getenv( 'CI' );
	if ( $scope->getTestResult()->getResultCode() <= 10 || $is_ci ) {