With significant-digits presentation mode, NAN would be formatted as
'NAN' followed by zeroes, which looks silly, and +INF would cause an
execution timeout as Moodle tries to divide +∞ by 10 until it becomes
less than 1, which can happen in a divide-by-zero situation.
Note that the user can't answer NAN or INF to any question, but at this
at least now looks consistent and also doesn't break Moodle in the case
of +INF.
Issue 1: While essay question's uploading progress, we need to disable submit
buttons to prevent submit form event.
Issue 2: Enable buttons after pressing cancel button on the popup
confirming overwrite file existed.
All these three strings were introduced in MDL-20296. The screenshots
there show some examples of where and how they were used. They stopped
being used shortly after in MDL-20636.
Given that they are specific strings with narrow semantic; they are
provided by a plugin and not by the core component; they have not been
used for 10 years; and no other plugin in the Plugins directory use
them, I feel we can safely bypass the deprecation phase and simply drop
them.
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.
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.
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).
