The following used steps were replaced by the ones
added in this issue:
- I fill the moodle form with
- I fill in with
- I select from
- I select radio button
- I check
- I uncheck
- the field should match
Also removing test for deprecated steps:
- the ASD checkbox should be checked
- the ASD checkbox should not be checked
In general aiming for compatibility with multiple browsers,
firefox, chrome and phantomjs to be more specific.
* Removing hardcoded waits
* Adding @_alert, @_switch_window and @_switch_frame tags,
to label actions that different drivers have problems with.
* Adding missing @_files_upload and @_only_local tags to features that
uploads files.
* Fixing a few wait for page ready what specified miliseconds.
* New methods to ensure elements (usual selectors), sections and editors
are ready to interact with
* Changing the select an option implementation to deal with the different
drivers implementations when listening to JS events.
- Escaping steps arguments redirected to other steps
- Adding normalized-space() in all contains() assertions
- General xpaths review
- Convering provided xpath text strings to xpath literals
to avoid problems with arguments containing both single
quotes and double quotes
1. Autosave works in some ways just like a normal save. We ultimately
call $behaviour->process_save() to do the work, and create a new step to
hold the data.
2. However, we come in through a completely different route through the
API, starting with separate auto-save methods. This keeps the auto-save
changes mostly separate, and so reduced the chance of breaking existing
working code.
3. When the time comes to store the auto-save step in the database, we
save it using a negative sequence number.
This is a clever trick that not only distinguises these steps, but also
avoids unique key errors when an auto-save and a real action happen
simultaneously. (There are unit tests for these tricky edge cases.)
4. When we load the data back from the database, most of the time the
auto-save steps are loaded back as if they were a real save, and so the
auto-saved data is used when the question is then rendered.
5. However, before we process another action, we remove the auto-saved
step, so it does not appear in the final history.
The problem was with the non-UTF-8-safe way that a question name
was being constructed from the question text.
I have done a proper fix with methods in the base class to
carefully construct a question name that is reasonable, and
which will fit in the database column. Then I have changed all
importers to use the new methods.
I also remembered not to break the lesson in the process.
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
