There are various places where it's not guaranteed that the
variable being used is array, and instead, can be null, bool, int...
We need to check that because php74 warns about it.
Where possible we have used the coalesce operator as
replacement for isset() ternary operations.
Before this fix, test_repeated_usage_saving_new_usage was failing but
test_repeated_usage_saving_existing_usage was passing. Now the
behaviour is consistent and they both pass.
This is a followup of 85f47ba, where we were relaxing
the (new since phpunit 7.x) strict (===) isEqual()
comparison for strings. Copying the explanations for
easier understanding.
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.
Users were getting confused between choice numbers and
group numbers. So choice numbers now show as [[1]] to
match what appears in the question text. Groups are now
letters A, B, ...
When the teacher is upgrading a previously entered grade, we re-display
exactly what they typed before if possible, rather than displaying with
a set number of decimal places.
This patch conbines valuable contributions from Kashmira Nagwekar and
Luca Bösch. Many thanks to them. However, the final form of the fix,
and hence the blame, falls to me -- Tim.
There were several issues here:
* The load_questions_usages_by_activity method in
question/engine/datalib.php was incorrectly treating the case
when no data was returned. (Looks like a historic copy-pase from
other methods that fetch one item by unique id, which therefore
must exist.)
* The report was not correctly handling the display when the 'Which
tries' was set to 'with, and without, attempts'.
* It was possible to select the 'All tries' option when also saying
'Users without attempts'. This combination makes not sense, so
a disabledIf rule was added to the form.
1. getMock()
2. setExpectedException()
3. checkForUnintentionallyCoveredCode renamed to beStrictAboutCoversAnnotation
4. beStrictAboutTestSize renamed to enforceTimeLimit
5. UnitTestCase class is now fully removed.
dirname() is a slow function compared with __DIR__ and using
'/../'. Moodle has a large number of legacy files that are included
each time a page loads and is not able to use an autoloader as it is
functional code. This allows those required includes to perform as
best as possible in this situation.
Previously, the Check button was often shown disabled when it
could not be used (e.g. when the question was finished, or when an
interactive question was in the try-again state). Eventually we
realised it was better usability to hide it in these cases.
Note that when a teacher reviews an in-progress quiz attempt, they will
see a disabled Check button if the student doing the quiz can see the
button.
