1. 12 Jun, 2017 1 commit
  2. 27 Apr, 2017 1 commit
  3. 23 Feb, 2017 1 commit
    • Test Speedup: Isolate Modulestore Signals · 2051c909
      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]
      David Ormsbee committed
  4. 03 Aug, 2016 1 commit
  5. 27 Jul, 2016 1 commit
  6. 16 Feb, 2016 2 commits
  7. 11 Feb, 2016 1 commit
  8. 08 Feb, 2016 1 commit
  9. 22 Jan, 2016 1 commit
  10. 14 Dec, 2015 1 commit
  11. 25 Nov, 2015 1 commit
  12. 08 Oct, 2015 1 commit
  13. 19 Aug, 2015 1 commit
  14. 07 May, 2015 1 commit
  15. 17 Mar, 2015 1 commit
  16. 04 Feb, 2015 2 commits
    • Better support specifying of modulestore configuration in test cases · b353ed2e
      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]
      Calen Pennington committed
  17. 02 Dec, 2014 1 commit
  18. 30 Nov, 2014 1 commit
  19. 12 Nov, 2014 1 commit
  20. 10 Nov, 2014 1 commit
  21. 09 Nov, 2014 1 commit
  22. 24 Sep, 2014 2 commits
  23. 23 Sep, 2014 1 commit
  24. 16 Sep, 2014 1 commit
  25. 10 Jul, 2014 1 commit
    • Separate edX / Open edX footer. · 3cb87802
      We need to use an Open edX footer by default (and that's what all non-edx.org
      instances should base their footer off) and only use the edX footer on
      edx.org.
      
      This commit uses `SITE_NAME` to determine which footer to use.
      
      Sites using theming or micro-sites with a `SITE_NAME` not ending in `edx.org`
      should not be affected.
      James Tauber committed
  26. 28 Feb, 2014 1 commit
  27. 10 Feb, 2014 1 commit
  28. 30 Jan, 2014 2 commits
  29. 23 Jan, 2014 1 commit
  30. 14 Jan, 2014 1 commit
    • Introduction of the Microsite feature which allows for limited multi-tenant… · a3211a74
      Introduction of the Microsite feature which allows for limited multi-tenant branding on a subdomain basis, e.g. foo.edx.org and bar.edx.org
      
      fix errorenous logic when running a microsite that could reside in a hosting environment with a marketing site in front of it
      
      pep8/pylint fixes
      
      address PR feedback, remove underscore from test hostname
      
      more pep8/pylint cleanup. Skip test_microsites test, it works on localdev, not on Jenkins. Need to talk with QA team
      
      manually add Ned's single-to-double quote fix
      
      change aws.py runtimes so that the microsite_dir that is read from configuration is changed to a python path
      
      Conflicts:
      	lms/templates/help_modal.html
      Chris Dodge committed