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
While this is not strictly required, because removal will
happen in PHPUnit 9.0, we are already getting rid of all
uses in core.
From release notes:https://phpunit.de/announcements/phpunit-8.html
assertInternalType() is deprecated and will be removed in
PHPUnit 9. Refactor your test to use assertIsArray(), assertIsBool(),
assertIsFloat(), assertIsInt(), assertIsNumeric(), assertIsObject(),
assertIsResource(), assertIsString(), assertIsScalar(),
assertIsCallable(), or assertIsIterable() instead.
All the setup/teardown/pre/post/conditions template methods
now are required to return void. This was warned with phpunit 7
and now is enforced.
At the same time, fix a few wrong function names,
provider data and param types, return statements...
In MDL-62853 a new clean_param(PARAM_PATH) was added to the
moodle_content_writer->get_path() method. And this caused some
Windows tests to start failing.
The problem is that clean_param(PARAM_PATH) does normalise directory
separators to be always forward backslashes and that's normally ok
but the get_path() method has some DIRECTORY_SEPARATOR dependent code
that stopped working under windows.
After analysing various solutions, and trying to keep the behavior
EXACTLY like it was before MDL-62853, but with the cleaning included
we have applied 2 changes:
b) Move the clean_param() to later within the array_map() function,
that way the code there, that uses DIRECTORY_SEPARATOR will continue
working the same.
b) As far as there are more DIRECTORY_SEPARATOR dependent code later
in the function, also perform a str_replace() to convert back to the
OS directory separator.
Those 2 points together (a and b) make the behavior to be 100% the
original one, with separators being kept and the paths being cleaned.
This solution corresponds 100% with the proposed fixes named 3) and
4) in the issue.
Final note... all that DIRECTORY_SEPARATOR maybe needs a review because
it really shouldn't be used unless strictly needed. But that falls out
from this issue which goal was to keep things safely working like they
were before the regression (but with the cleaning applied).
Before the patch, queries like:
SELECT 1 FROM dual UNION SELECT 2 FROM dual
were failing badly, with everything but the first numeric element
being ignored by the optimization.
So, being conservative, now we reduce the query being analysed,
ignoring any subquery, inline view (anything within parenthesis
in general) and, in the remaining query, if a boolean query (UNION,
MINUS, INTERSECT...) is found, we don't apply any optimization.
* We need to use is_numeric() in this case as is_int() would never
return true.
* Extend the supported cases, add support for SQL consisting just of
numerical value or selectinga numerical constant.
* Do not rely on any particulat letter case in provided SQL.
* Add unit tests for the new method. Even when it is a protected one, it
is an essential unit to be tested on its own.
