The existing pattern of using `override_settings(MODULESTORE=...)` prevented
us from having more than one layer of subclassing in modulestore tests.
In a structure like:
@override_settings(MODULESTORE=store_a)
class BaseTestCase(ModuleStoreTestCase):
def setUp(self):
# use store
@override_settings(MODULESTORE=store_b)
class ChildTestCase(BaseTestCase):
def setUp(self):
# use store
In this case, the store actions performed in `BaseTestCase` on behalf of
`ChildTestCase` would still use `store_a`, even though the `ChildTestCase`
had specified to use `store_b`. This is because the `override_settings`
decorator would be the innermost wrapper around the `BaseTestCase.setUp` method,
no matter what `ChildTestCase` does.
To remedy this, we move the call to `override_settings` into the
`ModuleStoreTestCase.setUp` method, and use a cleanup to remove the override.
Subclasses can just defined the `MODULESTORE` class attribute to specify which
modulestore to use _for the entire `setUp` chain_.
[PLAT-419]
This commit adds the non-courseware lms/djangoapps and lms/lib.
These keys are now objects with a limited interface, and the particular
internal representation is managed by the data storage layer (the
modulestore).
For the LMS, there should be no outward-facing changes to the system.
The keys are, for now, a change to internal representation only. For
Studio, the new serialized form of the keys is used in urls, to allow
for further migration in the future.
Co-Author: Andy Armstrong <andya@edx.org>
Co-Author: Christina Roberts <christina@edx.org>
Co-Author: David Baumgold <db@edx.org>
Co-Author: Diana Huang <dkh@edx.org>
Co-Author: Don Mitchell <dmitchell@edx.org>
Co-Author: Julia Hansbrough <julia@edx.org>
Co-Author: Nimisha Asthagiri <nasthagiri@edx.org>
Co-Author: Sarina Canelake <sarina@edx.org>
[LMS-2370]
Adds a split_test_module XModule, that can choose one of its children
to display, based on a get_condition_for_user API added to the runtime.
To test, add something like this to an xml course, or make equivalent
tweaks in mongo.
<vertical url_name="split_test_vert">
<split_test url_name="split1" experiment_id="0" condition_id_to_child='{"0": "i4x://MITx/6.00x/html/split_test_cond0", "1": "i4x://MITx/6.00x/html/split_test_cond1"}'>
<html url_name="split_test_cond0">condition 0</html>
<html url_name="split_test_cond1">condition 1</html>
</split_test>
</vertical>
Also needs an experiment configured in the course policy json: e.g.
"user_partitions": [{"id": 0,
"name": "Experiment 0",
"description": "Unicorns?",
"version": 1,
"groups": [{"id": 0,
"name": "group 0",
"version": 1},
{"id": 1,
"name": "group 1",
"version": 1}]}]
(This particular snippet will work inside a course with org MITx
and course name 6.00x)
Co-Author: Sarina Canelake <sarina@edx.org>
Co-Author: Julia Hansbrough <julia@edx.org>
Co-Author: Diana Huang <diana@edx.org>
Co-Author: Calen Pennington <cale@edx.org>
[LMS-2095]
This requires fixing the javascript api implementation, and adding
an implementation of get_block to the ModuleSystem api.
However, the implementation is incomplete, due to mismatches between
the expectations of XModule and XBlock.
Also adds tests using the Acid block to make sure that the javascript
and python apis for children are working correctly.
