Name |
Last commit
|
Last update |
---|---|---|
.. | ||
mock_cs_server | ||
__init__.py | ||
factories.py | ||
group_id.py | ||
test.mustache | ||
test_middleware.py | ||
test_models.py | ||
test_mustache_helpers.py | ||
test_utils.py | ||
unicode.py | ||
utils.py |
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]
Name |
Last commit
|
Last update |
---|---|---|
.. | ||
mock_cs_server | Loading commit data... | |
__init__.py | Loading commit data... | |
factories.py | Loading commit data... | |
group_id.py | Loading commit data... | |
test.mustache | Loading commit data... | |
test_middleware.py | Loading commit data... | |
test_models.py | Loading commit data... | |
test_mustache_helpers.py | Loading commit data... | |
test_utils.py | Loading commit data... | |
unicode.py | Loading commit data... | |
utils.py | Loading commit data... |