Fix failing tests when object cache is on

[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 focuses on enhancing the reliability of various WordPress CLI tests, particularly when an object cache is enabled. It addresses scenarios where direct database manipulations or deletions could lead to stale cached data, causing tests to fail. By strategically adding cache invalidation commands or skipping object cache for specific scenarios, the changes ensure that tests accurately reflect the state of the database and pass consistently across different environments.

Highlights

• Test Reliability: Ensured tests related to post comment counts are reliable when object caching is active by explicitly clearing the post cache after direct database updates.
• Cache Invalidation: Added a cache flush command after deleting menu items to prevent tests from failing due to stale cached data.
• Term Cache Management: Implemented explicit term cache clearing after direct database updates to term taxonomy counts, improving test stability with object caching.
• Scenario Tagging: Marked a specific scenario in option-list.feature to skip object cache, addressing potential inconsistencies in test environments.

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

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[gemini-code-assist]

Code Review

This pull request updates several feature files to improve test reliability by addressing caching issues. Specifically, it adds clean_post_cache and clean_term_cache calls after direct database updates in comment-recount.feature and term-recount.feature respectively, and introduces a wp cache flush command in menu-item.feature after item deletion. Additionally, the option-list.feature now includes an @skip-object-cache tag for a scenario, indicating a test that should bypass object caching. There is no feedback to provide.

[Copilot]

Pull request overview

Updates Behat acceptance tests to be resilient when an external/persistent object cache is enabled, avoiding stale reads after direct DB writes and adjusting transient-related expectations.

Changes:

• Clear relevant WordPress caches after direct $wpdb->update() calls in recount-related scenarios.
• Flush cache between menu-item delete and subsequent list to avoid stale menu hierarchy results.
• Add an object-cache-related skip tag to the transient listing scenario.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File	Description
features/term-recount.feature	Clears term cache after manual term_taxonomy.count update before asserting.
features/comment-recount.feature	Clears post cache after manual posts.comment_count update before asserting.
features/menu-item.feature	Flushes cache after deleting a menu item to avoid stale parent/child relationships.
features/option-list.feature	Adds @skip-object-cache tag to transient option listing scenario.

---

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

[Copilot]

The newly added @skip-object-cache tag doesn’t appear to be handled anywhere in this repository (no runner config/docs reference it), so it may have no effect unless the external test harness explicitly filters on it. To make this scenario reliably pass with object cache enabled, consider setting the transient rows directly in the options table (e.g. add _transient_* / _transient_timeout_* options) instead of relying on wp transient set, which bypasses DB storage when an external object cache is active.