There are a number of Django Signals that are on the modulestore's
SignalHandler class, such as SignalHandler.course_published. These
signals can trigger very expensive processes to occur, such as course
overview or block structures generation. Most of the time, the test
author doesn't care about these side-effects.
This commit does a few things:
* Converts the signals on SignalHandler to be instances of a new
SwitchedSignal class, that allows signal sending to be disabled.
* Creates a SignalIsolationMixin helper similar in spirit to the
CacheIsolationMixin, and adds it to the ModuleStoreIsolationMixin
(and thus to ModuleStoreTestCase and SharedModuleStoreTestCase).
* Converts our various tests to use this new mechanism. In some cases,
this means adjusting query counts downwards because they no longer
have to account for publishing listener actions.
Modulestore generated signals are now muted by default during test runs.
Calls to send() them will result in no-ops. You can choose to enable
specific signals for a given subclass of ModuleStoreTestCase or
SharedModuleStoreTestCase by specifying an ENABLED_SIGNALS class
attribute, like the following example:
from xmodule.modulestore.tests.django_utils import ModuleStoreTestCase
class MyPublishTestCase(ModuleStoreTestCase):
ENABLED_SIGNALS = ['course_published', 'pre_publish']
You should take great care when disabling signals outside of a
ModuleStoreTestCase or SharedModuleStoreTestCase, since they can leak
out into other tests. Be sure to always clean up, and never disable
signals outside of testing. Because signals are essentially process
globals, it can have a lot of unpleasant side-effects if we start
mucking around with them during live requests.
Overall, this change has cut the total test execution time for
edx-platform by a bit over a third, though we still spend a lot in
pre-test setup during our test builds.
[PERF-413]
Some StudentModule entries were written with newlines at the end of the
course_id. This script finds those entries within a given time range,
archive them, and merges records if necessary (capa problems).
This moves the functionality of the 'export_course' management command from lms/djangoapps/courseware
over to the Studio codebase. This reflects its use going forward to be run with cms settings, to
export the content of the Studio modulestore instead of the LMS modulestore. The management
command is used by an analytics workflow to output course content for researchers.
This is a clone (copy) of CSMH's declaration and methods with an added
id of UnsignedBigInAutoField
We should be able to delete the save_history code, but needs testing.
Add error logging when capa failures happen
Put StudentModuleHistory into its own database
Bump out the primary key on CSMHE
This gives us a gap to backfill as needed.
Since the new table's pk is an unsigned bigint, even for people who don't
consolidate CSMH into CSMHE, the lost rows are unlikely to matter.
Remove StudentModuleHistory cleaner
The old line:
from path import path
produced pylint errors because of the baroque way that path.py defined
"path". We tried to get them to change how they defined it, but they
deleted the name instead: https://github.com/jaraco/path.py/issues/102
(Jason then changed his mind, but this is a better way to use path.py,
it avoids the pylint error at least.)
This required the following changes to the DjangoXBlockUserStateClient
semantics:
1) Changes get/get_many to return XBlockUserState tuples, rather
than state dictionaries or (block_key, state) tuples.
2) Raises DoesNotExist if get_history is called on an XBlock that has
had no data saved to it.
3) Returns XBlockUserState tuples as the results of get_history.
While this may have served a purpose at one point, it's now been broken
for more than 2 years [1]; a critical code path makes a call to a
function which is no longer imported.
[1] commit 84cb0ce99b
Date: Fri Dec 21 13:15:37 2012 -0500
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]
Move modulestore config for tests to an importable location
Disable pylnt warning for lms imports in common tests
Refactor all testcases that loaded all xml courses
TE-610
TE-489
