This commit includes more changes, all them also adding the :void
return type to unit tests missing them.
The difference is that all these changes, while also detected
perfectly by the moodle.PHPUnit.TestReturnType sniff, were not
auto-fixed (like the previous commit ones), because all them
do include some "return" statement and, for safety, we don't
fix them.
All the cases have been visually inspected and confirmed that
the existing "return" statements always belong to anon
functions within the test body and not the test own return statement.
While this change is not 100% required now, it's good habit
and we are checking for it since Moodle 4.4.
All the changes in this commit have been applied automatically
using the moodle.PHPUnit.TestReturnType sniff and are, exclusively
adding the ": void" return types when missing.
The changes here are heterogeneous:
- Include stuff that is not available (other test has included it).
Sometimes local to a unit test, others in setupBeforeClass() or
globally, ... depends on every case.
- Rename some tests (namespaces, test name, ...) towards getting it
running.
- Amend small bits here and there.
Important note: I've left any "cosmetic" warning out from the
changes, only a few errors (like long array syntax) have been fixed.
When the question custom fields were deleted, if there were any
hidden columns in qbank Column sort order referring those fields they
were throwing 'Custom field does not exist' exception. Changes done to
ignore such fields and display valid hiddencols, as these references
were breaking the qbank Column sort order and Question bank pages.
Before Moodle 4.3, config_plugins settings for qbank_columnsortorder
(disabledcol, enabledcol) had a value like
qbank_statistics\columns\facility_index,
qbank_statistics\columns\discriminative_efficiency, ...
In Moodle 4.3, the values are stored as
qbank_statistics\columns\facility_index-facility_index.
So updating the old values to match the new format.
After discussing it in the issue, we have agreed to apply
the new phpunit_util::normalise_line_endings() method to
all the remaining cases (within tests!) where the manual
replacement was being done. This commits achieves that.
Note that I've looked for both str_replace() and preg_replace()
cases, but only the former had cases worth converting. All the
later ones are different and cannot be replaced by the new
utility method.
Users can now rearrange options using the move buttons that each option
have, therefore there is no need for the current unintuitive keyboard
interaction implementation in the ordering question type plugin.
Each option has a couple of buttons to move the option's position. This
allows moving options by single pointer without dragging to address WCAG
Success Criterion 2.5.7.
Having the buttons also addresses WCAG Success Criterion 2.1.1 as it
provides an intuitive way to move options using keyboard.
Fixes the failing unit tests in the ordering question type by
implementing the following adjustments and corrections:
- Ensure the missing required files are imported in
questionhint_test.php and questiontype_test.php.
- Modify the expected fraction values in testexport.moodle.xml to
accurately reflect the recent changes, specifically the type
casting of the fraction value stored for each answer into the
question object.
- Reorder the items in the answers array within the failing scenario
in specific_grade_detail_feedback_test.php to guarantee that, in
accordance with the randomly generated subset of correct answers,
the question attempt will consistently be incorrect as required.
- Pass the answer codes in the order of the defined response when
calling the process_submission() function in feedback_test.php
to ensure the response in the current question attempt is properly
set, rather than relying on random generation of the response which
may result in random test failures.
When retrieving the answer data from the database, it's essential to
cast the value of the answer's fraction to a float before storing it
into the question object. This step is crucial for ensuring consistency,
as some database engines return floats as strings like '1.0000000'.
