test for wp_schedule_delete_old_privacy_export_files

[pbearne]

Trac ticket: https://core.trac.wordpress.org/ticket/59707

[github-actions]

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 props-bot label.

Unlinked Accounts

The following contributors have not linked their GitHub and WordPress.org accounts: @pbearne@git.wordpress.org.

Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases.

Core Committers: Use this line as a base for the props when committing in SVN:

Props pbearne, wildworks, mindctrl, masteradhoc, roshniahuja14.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Test using WordPress Playground

The 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

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[masteradhoc]

@pbearne could you check the last feedback from @mindctrl? i'd like to milestone this for 7.1 so we can get this added soon.

[roshniahuja]

Thanks @pbearne for the patch. I've prepared a refreshed version of the test that resolves the outstanding review feedback from @mindctrl on this PR:

• Calls parent::set_up() / parent::tear_down().
• Moves the wp_installing( false ) reset into tear_down() so it always runs even if an assertion fails.
• Adds a third test, test_wp_schedule_delete_old_privacy_export_files_already_scheduled(), covering the branch where the event is already scheduled (no duplicate is created).
• Adds a standard file docblock, @group privacy (the ticket's reassigned component), and assertion failure messages.

Verified locally against trunk: OK (3 tests, 5 assertions), and PHPCS is clean.

Branch: https://github.com/roshniahuja/wordpress-develop/tree/59707-test-wp-schedule-delete-old-privacy-export-files

[roshniahuja]

For visibility: I've also opened #12563 as an alternative PR carrying these same tests, in case that's an easier path to land than updating this branch. Happy to close it and fold the changes in here instead — whichever maintainers prefer. See #59707.

[Copilot]

Pull request overview

Adds PHPUnit coverage for wp_schedule_delete_old_privacy_export_files() (Trac #59707) to ensure the cron event is scheduled appropriately and not duplicated.

Changes:

• Introduces a new test class covering initial scheduling behavior.
• Adds a test to ensure no scheduling occurs during installation mode.
• Adds a test to ensure re-calling the function does not create duplicate cron events.

Comments suppressed due to low confidence (1)

tests/phpunit/tests/functions/wpScheduleDeleteOldPrivacyExportFiles.php:47

• Calling parent::tear_down() inside an individual test method is incorrect; tear_down() should be handled by PHPUnit, and this call can run cleanup at the wrong time. Once tear_down() correctly calls parent::tear_down(), this line should be removed.

		wp_schedule_delete_old_privacy_export_files();
		$this->assertFalse( wp_next_scheduled( 'wp_privacy_delete_old_export_files' ) );
		parent::tear_down();
	}

---

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

[t-hamano]

@pbearne, Can you address the feedback from Copilot? Both seem like reasonable suggestions.

[masteradhoc]

Thank you @pbearne! The PR would be ready for another review and merge. @t-hamano Can you help out here?

[t-hamano]

Suggested change

	wp_schedule_delete_old_privacy_export_files();
	$first = wp_next_scheduled( 'wp_privacy_delete_old_export_files' );
	wp_schedule_delete_old_privacy_export_files();
	$this->assertSame( $first, wp_next_scheduled( 'wp_privacy_delete_old_export_files' ) );
	// Schedule ahead of time() so that a duplicate would land on a different timestamp.
	wp_schedule_event( strtotime( '+1 hour' ), 'hourly', 'wp_privacy_delete_old_export_files' );
	// Take a snapshot of the cron option while the event is scheduled.
	$expected = _get_cron_array();
	// The event is already scheduled, so this call should be a no-op.
	wp_schedule_delete_old_privacy_export_files();
	// Check cron option is unchanged.
	$this->assertSame( $expected, _get_cron_array(), 'the event should not be scheduled again' );

This assertion doesn't currently catch a regression — removing the ! wp_next_scheduled() guard leaves this test green. Two reasons:

1. wp_schedule_event() stores events as $crons[ $timestamp ][ $hook ][ md5( serialize( $args ) ) ]. This function always schedules with no args, so both calls collide on all three keys when they happen within the same second — the second one silently overwrites the first, and no duplicate is ever observable.
2. Even if the two calls land on different seconds, wp_next_scheduled() only returns the soonest timestamp, so it still returns $first and the assertion passes.

Seeding the event at a timestamp other than time() and comparing the whole cron option would cover both cases:

This follows the same pattern as test_pre_schedule_event_filter().

[t-hamano]

Suggested change

	// set to installing mode
	$prior = wp_installing();
	wp_installing( true );
	$this->assertFalse( wp_next_scheduled( 'wp_privacy_delete_old_export_files' ), 'no export should be scheduled' );
	wp_schedule_delete_old_privacy_export_files();
	$this->assertFalse( wp_next_scheduled( 'wp_privacy_delete_old_export_files' ), 'export should be scheduled' );
	wp_installing( $prior );
	$this->assertFalse( wp_next_scheduled( 'wp_privacy_delete_old_export_files' ), 'no export should be scheduled' );
	// set to installing mode
	$prior = wp_installing();
	wp_installing( true );
	wp_schedule_delete_old_privacy_export_files();
	wp_installing( $prior );
	$this->assertFalse( wp_next_scheduled( 'wp_privacy_delete_old_export_files' ), 'no export should be scheduled while installing' );

Since the installing mode restoration occurs after the assertion, if the assertion fails, the installing mode is not restored, which affects subsequent tests. I believe we need to be careful about the order to ensure that the installing mode is always restored regardless of whether the assertion succeeds or fails.

Also, please note that the message has been changed from export should be scheduled to no export should be scheduled while installing. The previous message indicated the opposite of the assertion.