Add an ExtensionTestCase to allow testing of the models of Review Board extensions
Review Request #6821 — Created Jan. 22, 2015 and discarded
| Information | |
|---|---|
| brennie | |
| Review Board | |
| master | |
| Reviewers | |
| reviewboard | |
The
ExtensionTestCaseclass is a special test case base class for
Review Board extensions. It exposes the models of the extension via
themodelsattribute on instances of the sub-class.To run tests on the extension, execute
./reviewboard/manage.py test -- extension.tests
whereextensions.testis the module containing the tests.
Created an extension with a model. Subclassed
ExtensionTestCase
and created test methods that passed on that subclass.
| Description | From | Last Updated |
|---|---|---|
|
The general import statements go before the from ... imports. |
 chipx86
|
|
|
Mixins should go before the parent classes. |
chipx86
|
|
|
Missing period at the end. |
chipx86
|
|
|
Django's ImproperlyConfigured exception would be a good one to use here. |
chipx86
|
|
|
There's no guarantee that this lives in a module named "extension," I don't believe. Can we have the consumer just … |
chipx86
|
|
|
We don't always want this enabled up-front. Often, you want to test what happens when enabling an extension, and need … |
chipx86
|
|
|
These should also call the parent functions. |
chipx86
|
|
|
Col: 9 E303 too many blank lines (2) |
 reviewbot
|
-
Awesome to have real progress on this!
It doesn't look like anything in here is RB-specific, aside from fetching the ExtensionManager. How about moving most of this into Djblets, and then having this subclass just provide the extension manager?
-
reviewboard/testing/extensions.py (Diff revision 1) The general
importstatements go before thefrom ...imports. -
-
-
reviewboard/testing/extensions.py (Diff revision 1) Django's
ImproperlyConfiguredexception would be a good one to use here. -
reviewboard/testing/extensions.py (Diff revision 1) There's no guarantee that this lives in a module named "extension," I don't believe. Can we have the consumer just supply the extension class instance, and compute it from that, like:
extension_id = '%s.%s' % (cls.extension.__module__, cls.extension.__name__) -
reviewboard/testing/extensions.py (Diff revision 1) We don't always want this enabled up-front. Often, you want to test what happens when enabling an extension, and need to set things up up-front. I'd leave this out and just let the subclass decide whether to call this in
setUpor in a test function. -
-
Tool: PEP8 Style Checker Processed Files: reviewboard/testing/extensions.py Tool: Pyflakes Processed Files: reviewboard/testing/extensions.py -
-
Tool: Pyflakes Processed Files: reviewboard/testing/extensions.py Tool: PEP8 Style Checker Processed Files: reviewboard/testing/extensions.py
Tool: PEP8 Style Checker Processed Files: reviewboard/testing/extensions.py Tool: Pyflakes Processed Files: reviewboard/testing/extensions.py