| Name |
Last commit
|
Last update |
|---|---|---|
| .. | ||
| features | ||
| management | ||
| migrations | ||
| tests | ||
| views | ||
| __init__.py | ||
| admin.py | ||
| context_processors.py | ||
| course_info_model.py | ||
| debug_file_uploader.py | ||
| git_export_utils.py | ||
| models.py | ||
| tasks.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 |
|---|---|---|
| .. | ||
| features | Loading commit data... | |
| management | Loading commit data... | |
| migrations | Loading commit data... | |
| tests | Loading commit data... | |
| views | Loading commit data... | |
| __init__.py | Loading commit data... | |
| admin.py | Loading commit data... | |
| context_processors.py | Loading commit data... | |
| course_info_model.py | Loading commit data... | |
| debug_file_uploader.py | Loading commit data... | |
| git_export_utils.py | Loading commit data... | |
| models.py | Loading commit data... | |
| tasks.py | Loading commit data... | |
| utils.py | Loading commit data... |