Custom rules are combined using the AND operator. However, the
'completionpass' and 'completionattemptsexhausted' rules are exceptions
because they are combined together with OR, and form a single new rule
that then will be combined with the rest of the rules using AND.
This commit combines the mentioned rules into a single rule named
'completionpassorattemptsexhausted'.
This change removes references in code and comments to a few
deprecated functions that were accidentally missed in the larger
change.
The code changes only affect service_users.php. I made it support
custom user profile fields in this query, because it was easy
enough, rather than adding another TODO to fix later.
This class would belong more appropriately within the 'user' API
(core_user) instead of within the 'core' API, since it is
directly related to user data.
Since the class has only just been added to Moodle, now is a good
time to move it.
The link to the calendar page is missing in the navigation block in
classic which causes a behat failure in the 'Set availibility dates
for an assignment' feature. The fix includes adding the calendar block
to the Course page which can be used to navigate to the calendar page.
Using the external method for updating posts, the check for empty
subject/message content wasn't correct (disallowed the string '0'),
in addition to being impossible to set a posts message format
property to FORMAT_MOODLE (integer 0).
I've gone over a few of the mofified files (those
which were showing warnings and errors to CiBoT. Some of them
have been fixed completely, while others only have fixed
for the lines belonging to this issue (lib/tests/moodlelib_test.php)
for example.
This applies the "whitelist" => "include" changes to all the core
phpunit_coverage_info occurrences, so core won't emit any deprecation
warning (see previous commit).
At the same time, modified a bunch of comments in coverage files
to be more readable/understandable.
The current ->setMethods() has been silently (won't emit any
warning) in PHPUnit 9. And will stop working (current plans)
in PHPUnit 10.
Basically the now deprecated method has been split into:
- onlyMethods(): To point to existing methods in the mocked artifact.
- addMethods(): To point to non existing (yet) methods in the mocked
artifact.
In practice that means that all our current setMethods() calls can be
converted to onlyMethods() (existing) and done. The addMethods() is
mostly useful on development phases, not final testing.
Finally note that <null> isn't accepted anymore as parameter to
double all the methods. Instead empty array [] must be used.
Link: https://github.com/sebastianbergmann/phpunit/issues/3770
The methods assertContains() and assertNotContains() now perform
strict (type and value) comparison, pretty much like assertSame()
does.
A couple of new assertContainsEquals() and assertNotContainsEquals()
methods have been created to provide old (non-strict) behavior, pretty
much like assertEquals() do.
Apart from replacing the calls needing a relaxed comparison to those
new methods, there are also a couple of alternative, about how to
fix this, depending of every case:
- If the test is making any array_values() conversion, then it's better
to remove that conversion and use assertArrayHasKey(), that is not
strict.
- Sometimes if may be also possible to, simply, cast the expectation
to the exact type coming in the array. I've not applied this technique
to any of the cases in core.
Link: https://github.com/sebastianbergmann/phpunit/issues/3426
In PHPUnit 9.1, the following regexp-related assertions
have been deprecated and there are new alternatives for
all them:
- assertRegExp() -> assertMatchesRegularExpression()
- assertNotRegExp() -> assertDoesNotMatchRegularExpression()
This is about to, simply, move all cases to the new alternatives.
Source: https://github.com/sebastianbergmann/phpunit/blob/9.1.0/ChangeLog-9.1.md
Regexp to find all them:
ag 'assertRegExp|assertNotRegExp' -li
In all cases changes have been kept to a minimum while not making
the code completely horrible. For example, there are many instances
where it would probably be better to rewrite a query entirely, but
I have not done that (in order to reduce the risk of changes).
