- Part of: MDL-69588
A lot of tests work on the basis that you can follow the last item
of the breadcrumb nav bar. This is not the case. This step will first
check to see if the page is already the one requested. If it is then
nothing further needs to happen, otherwise we follow the link in the
navbar.
The optional parameters of assertEquals() and assertNotEquals()
are deprecated in PHPUnit 8 (to be removed in PHPUnit 9):
- delta => use assertEqualsWithDelta()
- canonicalize => use assertEqualsCanonicalizing()
- ignoreCase => use assertEqualsIgnoringCase
- maxDepth => removed without replacement.
More info @ https://github.com/sebastianbergmann/phpunit/issues/3341
Initial search done with:
ag 'assert(Not)?Equals\(.*,.*,' --php
Then, running tests and fixing remaining cases.
Both assertContains() and assertNotContains() are deprecated in PHPUnit 8
for operations on strings. Also the optional case parameter is. All uses
must be changed to one of:
- assertStringContainsString()
- assertStringContainsStringIgnoringCase()
- assertStringNotContainsString()
- assertStringNotContainsStringIgnoringCase()
More info: https://github.com/sebastianbergmann/phpunit/issues/3422
Regexp to find all uses:
ag 'assert(Not)?Contains\('
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
The annotations `@expectedException`, `@expectedExceptionCode`,
`@expectedExceptionMessage`, and `@expectedExceptionMessageRegExp`
are now deprecated.
Using these annotations will trigger a deprecation warning
in PHPUnit 8 and in PHPUnit 9 these annotations will be removed.
Also, all uses of expectExceptionMessageRegExp() has been moved
to expectExceptionMessageMatches(). See https://github.com/sebastianbergmann/phpunit/issues/3957
TODO: Various weirdness found while doing the changes with these tests:
- vendor/bin/phpunit lib/tests/exporter_test.php (created MDL-69700)
- vendor/bin/phpunit competency/tests/external_test.php (same issue than prev one)
- vendor/bin/phpunit question/engine/tests/questionengine_test.php (created MDL-69624)
- vendor/bin/phpunit lib/tests/event_test.php (created MDL-69688)
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...
When some activities are manually completed by students, some are still showing in students' timeline.
This commit fix that for module assign,chat,choice,feedback,lesson,quiz,scorm and workshop.
Namely:
- 3rd param of assertEquals() cannot be null.
- Some incorrect uses of assertNotEmpty().
- Comparing 2 strings now uses strict (===) evaluation.
Link: https://github.com/sebastianbergmann/phpunit/issues/3185
Solution here is one of:
a) Return to the previous situation, making the comparison
softer. That can achieved by forcing different types, so
float == string works.
b) Changing APIs (both forms and database return strings) to
perform some conversion to floats. That would make float
comparison (with floats or strings) to work too.
The patch here follows the a) approach. Changing all the internals
for proper float handling sounds excesive when it has been working
perfectly since ever. So we went the easier route, just getting
rid of the new === comparisons when needed by changing expectation
types to float.
There was a bug here that had not exposed until MDL-60820 introduced the
call $mform->setDefault() at the bottom of the definition_after_data()
method. That call triggers the 'updateValue' event on all form elements.
For input text elements, this effectively sets their value to the
default one, which was empty in this case due to the way how the value
had been set.
The solution here is to set the value via the same way like the normal
set_data() method does it.
The attached Behat test reproduces the problem and makes sure the patch
works.
The mod_workshop\privacy\provider now implements the new
core_userlist_provider interface. Deleting (erasing) data follows the
same principles as in other existing methods - we do not actually delete
data that might affect other users. Instead, we only erase the sensitive
owned personal information such as provided content.
This allows the teacher to define what students are supposed to submit
(online text and/or attachment) and if the given submission part is
required or optional.
Workshop module stores personal data in its tables, via user
preference and via core_files and core_plagiarism subsystems.
When exporting the data, we export not only data created by users
themselves (such as their submissions and provided peer-assessments) but
also all relevant data that can (or must) be used to interpret created
content and evaluate the user's performance and skills.
On the other hand, when deleting data at user's request, we delete only
those data that do not affect other users' performance evaluation. The
reasoning is that one's right for privacy does not overweight someone
else's right for fair assessment. For that reason, we can't fully delete
whole provided peer-assessments, for example. Because they are used in
cross-comparison and grading evaluation of all other peers who assessed
the same submission. So instead, we replace provided texts but still
keep the original record.
Workshop defines the interface for its grading strategy subplugins to
allow them attach personal data under their control to the exported
structures.
Ilya Tregubov