Tests: Add end-to-end coverage for scheduled post publishing.#12668
Tests: Add end-to-end coverage for scheduled post publishing.#12668csmcneill wants to merge 3 commits into
Conversation
Exercises a true future-to-publish transition through WP-Cron: the test schedules a post by the server's clock, waits out the scheduled time without issuing requests (an ordinary request that observes the due event would take the doing_cron lock, and the local Docker environment cannot perform the loopback spawn that releases useful work from it), then drives wp-cron.php explicitly and asserts the transition. Also covers the Scheduled posts list view. See #52895. Co-Authored-By: Craft Agent <agents-noreply@craft.do>
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the Core Committers: Use this line as a base for the props when committing in SVN: To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
There was a problem hiding this comment.
Pull request overview
Adds new Playwright end-to-end coverage to verify WordPress scheduled posts both (a) transition from future → publish via a real WP-Cron run and (b) appear in the admin posts list “Scheduled” view.
Changes:
- Introduces an e2e spec that schedules a post based on the server’s HTTP
Dateheader to avoid host/container clock skew. - Adds a deterministic “future-to-publish” transition check by driving
wp-cron.phpdirectly after the scheduled time elapses. - Adds coverage for the admin “Scheduled” status view showing the scheduled post and its scheduled date.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Test using WordPress PlaygroundThe changes in this pull request can previewed and tested using a WordPress Playground instance. WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser. Some things to be aware of
For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation. |
- Send date_gmt with an explicit UTC designator. - Fail clearly when the server response has no Date header. - Drive wp-cron.php once, before the status poll, so polling cannot spawn cron and re-arm the doing_cron lock against a later drive. Co-Authored-By: Craft Agent <agents-noreply@craft.do>
The spec spans real time by design (a 65-second quiet wait plus up to 60 seconds of polling), which can exceed the default 100-second per-test timeout on the failure path. test.slow() keeps a genuine failure surfacing as the poll's message instead of a test timeout. Co-Authored-By: Craft Agent <agents-noreply@craft.do>
Adds end-to-end coverage for scheduled post publishing: a true future-to-publish transition through WP-Cron, plus the Scheduled view of the posts list.
As far as I can tell, no e2e test currently exercises the actual cron transition — existing coverage stops at "the post is scheduled". The transition test schedules a post 60 seconds out by the server's own clock (read from an HTTP Date header, so host/container clock skew doesn't matter), lets the scheduled time pass, then drives wp-cron.php explicitly and asserts the status flip.
Two environment realities shaped the design and are documented in the spec:
Trac ticket: https://core.trac.wordpress.org/ticket/52895
Verification
Use of AI Tools
AI assistance: Yes
Tool(s): Claude (Claude Code via Craft Agents)
Agent(s): Fable 5
Used for: Test authoring and cross-environment verification, with human review; reviewed and submitted by the author.
This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.