djblets.testing.testcases¶
-
class
TestCase
(methodName=’runTest’)[source]¶ Bases:
django.test.testcases.TestCase
Base class for test cases.
Individual tests on this TestCase can use the
add_fixtures()
decorator to add or replace the fixtures used for the test.-
shortDescription
()[source]¶ Returns the description of the current test.
This changes the default behavior to replace all newlines with spaces, allowing a test description to span lines. It should still be kept short, though.
-
assertRaisesValidationError
(expected_messages, *args, **kwargs)[source]¶ Assert that a ValidationError is raised with the given message(s).
This is a wrapper around
assertRaisesMessage()
with aValidationError
that handles converting the expected messages into a list (if it isn’t already) and then converting that into a string representation, which is whatassertRaisesMessage()
will be checking against.Parameters: - expected_messages (list or unicode) – The expected messages as either a list of strings or a single string.
- args – Additional arguments to pass to
assertRaisesMessage()
. - kwargs – Additional keyword arguments to pass to
assertRaisesMessage()
.
-
-
class
TestModelsLoaderMixin
[source]¶ Bases:
object
Allows unit test modules to provide models to test against.
This allows a unit test file to provide models that will be synced to the database and flushed after tests. These can be tested against in any unit tests.
Typically, Django requires any test directories to be pre-added to INSTALLED_APPS, and a models.py made available (in Django < 1.7), in order for models to be created in the test database.
This mixin works around this by dynamically adding the module to INSTALLED_APPS and forcing the database to be synced. It also will generate a fake ‘models’ module to satisfy Django’s requirement, if one doesn’t already exist.
By default, this will assume that the test class’s module is the one that should be added to INSTALLED_APPS. This can be changed by overriding
tests_app
.
-
class
FixturesCompilerMixin
[source]¶ Bases:
object
Compiles and efficiently loads fixtures into a test suite.
Unlike Django’s standard fixture support, this doesn’t re-discover and re-deserialize the referenced fixtures every time they’re needed. Instead, it precompiles the fixtures the first time they’re found and reuses their objects for future tests.
However, also unlike Django’s, this does not accept compressed or non-JSON fixtures.
-
load_fixtures
(fixtures, db=’default’)[source]¶ Load fixtures for the current test.
This is called for every fixture in the test case’s
fixtures
list. It can also be called by an individual test to add additional fixtures on top of that.Parameters: - fixtures (list of unicode) – The list of fixtures to load.
- db (unicode) – The database name to load fixture data on.
-
-
class
TagTest
(methodName=’runTest’)[source]¶ Bases:
djblets.testing.testcases.TestCase
Base testing setup for custom template tags
-
class
StoppableWSGIServer
(*args, **kwargs)[source]¶ Bases:
django.core.servers.basehttp.WSGIServer
WSGIServer with short timeout, so that server thread can stop this server.
-
class
WSGIRequestHandler
(*args, **kwargs)[source]¶ Bases:
django.core.servers.basehttp.WSGIRequestHandler
A custom WSGIRequestHandler that logs all output to stdout.
Normally, WSGIRequestHandler will color-code messages and log them to stderr. It also filters out admin and favicon.ico requests. We don’t need any of this, and certainly don’t want it in stderr, as we’d like to only show it on failure.
-
class
TestServerThread
(address, port)[source]¶ Bases:
threading.Thread
Thread for running a http server while tests are running.