Make WordPress Core

Opened 5 years ago

Last modified 5 years ago

#47590 new defect (bug)

Add unit tests for requests to wp-cron.php

Reported by: peterwilsoncc's profile peterwilsoncc Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Cron API Keywords: needs-patch needs-unit-tests
Focuses: Cc:


  1. Ensure scheduled events are rescheduled correctly
  2. Ensure single events are removed from the cron array
  3. Ensure future events are not changed.
  4. Ensure doing_cron transient is deleted.

Change History (3)

#1 @desrosj
5 years ago

  • Keywords good-first-bug added
  • Milestone changed from Awaiting Review to Future Release

Going to mark good first bug. Seems like a good ticket for someone to dive in and learn unit tests.

#2 @markedgarwilliamson
5 years ago

@peterwilsoncc, I am new to making WordPress, and thought this bug might be a good place for me to start. I believe I have a good feel for the way the process works from the Handbook, and have my PHPUnit environment set up and working.

Once I started to take a look at this bug I found myself a little confused about the expectations regarding the cron info array. In #1 from your list, I learned that after using wp_schedule_event() for an event with a timestamp from '30 minutes ago', 'hourly' as a recurrence, a hook, and no args, using wp_reschedule_event() with the same timestamp, 'daily' as a recurrence, the same hook, and no args does add the event with the new recurrence, but does not remove the former event from the cron array.

My expectation was that rescheduling would remove the former event and add the event with the new schedule. However, I also realized this was an assumption I had made, based on my own intuition. So, I have been looking for more information in the documentation about the expectations of the cron info array. Unfortunately, I cannot seem to find that specific information quite yet. In case my intuition is wrong, and the cron info array is expected to retain past events when they are rescheduled, I started using wp_get_scheduled_event() without a timestamp to get the 'next scheduled event' for the given hook, but found that this function returned the original event with a timestamp in the past.

Between my research attempts with the API documentation, I have worked with the test case to narrow down my experience testing wp_reschedule_event() to three possible realities:

  1. I am doing something wrong altogether,
  2. wp_reschedule_event() is failing to remove the original event that is being rescheduled, or
  3. wp_get_scheduled_event() is failing to return the 'next scheduled event' when an event matching the hook but with a past timestamp is found from the cron info array before the actual next scheduled event.

I don't know if this is premature, but I thought I'd go ahead and add a comment for now to see if you or someone else might be in a position to shed more light on the expectation about the cron info array. If you have questions, concerns, or suggestions for me, please let me know. Thank you for your time and attention.


         * Ensure scheduled events are rescheduled correctly.
         * @ticket 47590
        function test_wp_reschedule_event() {
                $hook = __FUNCTION__;
                $ts1  = strtotime( '-30 minutes' );

                // Add an event.
                $this->assertTrue( wp_schedule_event( $ts1, 'hourly', $hook ) );

                // Reschedule event.
                $this->assertTrue( wp_reschedule_event( $ts1, 'daily', $hook ) );

                // Check cron schedule is changed.
                $this->assertSame( 'daily', wp_get_scheduled_event( $hook )->schedule );

#3 @peterwilsoncc
5 years ago

  • Keywords good-first-bug removed

@markedgarwilliamson Thanks for taking a look at this.

I apologize but the description of the ticket may have been confusing which has sent you down the wrong path.

The functions in /wp-includes/cron.php already have unit tests. These can be found in /tests/phpunit/tests/cron.php.

My goal is to add tests for calls to as it's currently untested. This is the file that triggers the running of registered cron jobs.

I'm not sure how best to test this myself as it's testing a WordPress entry point rather than testing a particular WordPress function. I've removed the good-first-bug keyword as I think there are much less confusing tickets to start with.

You asked if you were doing something wrong altogether. This is definitely not the case, any attempt to contribute to WordPress is of assistance and greatly appreciated!

Note: See TracTickets for help on using tickets.