Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-58723

core_calendar_rrule_manager_testcase generates too many assertions

XMLWordPrintable

    • MOODLE_31_STABLE, MOODLE_32_STABLE, MOODLE_33_STABLE
    • MOODLE_32_STABLE, MOODLE_33_STABLE
    • MDL-58723-master
    • Hide
      Before the patch (e.g. on the latest release: 2017042600.00)
      1. Run PHPUnit tests for the core_calendar_testsuite. 

        vendor/bin/phpunit --testsuite core_calendar_testsuite

        Or if using MDK

        mdk phpunit -r -s core_calendar

      2. Take note of the number of assertions and the time it took for the tests to complete (it might have around 28843 assertions).
      After the patch
      1. Update to the latest integration branch with the patch applied.
      2. Run again the core_calendar PHPUnit test suite.
        • Confirm that all tests pass.
      3. Take note of the execution time and the number of assertions.
        • Confirm that there are way less assertions now (around 4620 assertions).
        • Confirm that the execution time is faster than before the patch was applied.
      Show
      Before the patch (e.g. on the latest release: 2017042600.00) Run PHPUnit tests for the core_calendar_testsuite. vendor/bin/phpunit --testsuite core_calendar_testsuite Or if using MDK mdk phpunit -r -s core_calendar Take note of the number of assertions and the time it took for the tests to complete (it might have around 28843 assertions). After the patch Update to the latest integration branch with the patch applied. Run again the core_calendar PHPUnit test suite. Confirm that all tests pass. Take note of the execution time and the number of assertions. Confirm that there are way less assertions now (around 4620 assertions). Confirm that the execution time is faster than before the patch was applied.

      As poltawski commented, this unit test creates a bunch of assertions that checks every recurring event that has been generated. This can become quite a lot (28094 assertions) currently especially for checking events that recur forever (RRULEs without COUNT nor UNTIL rules) since:

      1. 'forever recurring' events are events that extend up to 10 years from the current date.
      2. The starting date that is being used in the rrule manager test is based from the examples of the RFC, which is usually 02-09-1997. (Imagine Moodle in 100 years. This particular test would have created way more assertions than today. Yikes!)

      Proposed solution:

      1. Modify the start dates of these forever recurring events to the current date.
      2. Evaluate only the first 100 records for the tests for forever recurring events. 100 samples should be enough to verify that the recurring events have been correctly generated.

            jpataleta Jun Pataleta
            jpataleta Jun Pataleta
            Adrian Greeve Adrian Greeve
            Jake Dallimore Jake Dallimore
            cameron1729 cameron1729
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved:

                Error rendering 'clockify-timesheets-time-tracking-reports:timer-sidebar'. Please contact your Jira administrators.