This affects the subquestions that appear as an embedded text input box.
There are three cases:
1. Input for subq left blank
2. Input for subq was wrong, and matched by a * wildcard.
3. Input for subq was wrong, and did not match any answer.
2. and 3. should look identical, apart from any feedback in case 2.
1. is different. The state should be displayed as "Not answered" even
though the mark for this part is still shown as 0.
There are some new unit tests for these cases.
Also, we slighly improve handling of , for decimal point in multianswer,
although there are still issues.
While working on this, I made some minor clean-ups in shortanswer and
numerical qtypes.
Three things:
1. Fixes to select expectation.
2. Fixes to match walkthrough tests (No idea how these managed to pass
under Simpletest!)
3. Fix expected values for multianswer upgrade tests.
1/ type/match/tests/walkthrough_test.php - tests are failing randomly, looks like some weird randomisation is going on there - see TODOs
2/ type/multianswer/tests/upgradelibnewqe_test.php contains invalid expected value - see TODO
The files that belong to the question hints are neither moved when the
question is moved to another context, nor deleted when the question is
deleted.
Oops! How come no one noticed that until today.
1. So we will truncate the question summary to 65000 chars if necessary.
2. Also, fix one minor error in mutlianswer save_question_options.
question_bank::MAX_SUMMARY_LENGTH is not the most logical class to add
the constant to, but it needs to be accessible during upgrade, so I was
lazy and put it there.
This commit also includes a lot of useful tidying up of some of the unit
test helper code. I turned out that I could not use all the helper code
in my new tests, but despite that it will be useful in the future, so I
am committing it here.
It is effectively impossible to compute the right random guess score, so we should not compute anything, rather than computing a number that we know is wrong.
This patch also fixes a multianswer unit test error that was shown up by this fix.
Probably easiest to explain by example: If the right answer is 1.23 m with alternate
unit 100 cm = 1m then the completely right answers are 1.23 m and 123 cm.
Right answer, wrong unit responses include 1.23, 1.23 frogs and 1.23 cm.
123 m is not considered to have the correct numerical value.
We may well re-consider the way this works in a future version of Moodle.
Unit grading was not implemented before Moodle 2.0. In Moodle 2.0, the unit grading
was more permissive than here, for example 123 m would have been graded correctly in
2.0. However, I'm not sure I follow the rationale for that.
There were two main problems:
1. The unit tests for upgrading adaptive quiz attempts had slighly the
wrong $expectedqa, and so matching that the upgrade was doing the wrong
thing in certain situations. The main issue was that it was setting
-_try = 1 on the first step, which broke the penalty calculation when
the quiz was regraded. There were also some other subtleties with
incrementing -_try that were not right before.
2. It was possible in 2.0 and earlier for two question_states to get the
same seq_number, and restoring 2.0 backups was rashly assuming that that
was unique.
Frederic Massart