Testing Mixins¶
Collection of functionality mix-ins.
This module contains standalone classes that can be safely mixed
into the BaseTest
class. Each mixin
extends the functionality of the test case by adding behaviors,
methods, and attributes - for example, patching well-understood
functionality or automatically creating/destroying an in memory
UDP server.
When creating a mixin it is important to take not that you
should strive to keep the Method Resolution Order (MRO) as clean
as possible. Each mixin class should ideally only inherit from
object
.
-
class
test_helpers.mixins.
EnvironmentMixin
¶ Mix this class in if you manipulate environment variables.
A common problem in testing code that uses environment variables is forgetting that they are really globals that persist between tests. This mixin exposes methods that make it easy and safe to set and unset environment variables while ensuring that the environment will be restored when the test has completed.
You need to mix this in over a class that calls the
configure
annihilate
class methods around the code under test such astest_helpers.bases.BaseTest
.-
classmethod
annihilate
()¶
-
classmethod
configure
()¶
-
classmethod
set_environment_variable
(name, value)¶ Set the value of an environment variable.
-
classmethod
unset_environment_variable
(name)¶ Clear an environment variable.
-
classmethod
-
class
test_helpers.mixins.
PatchMixin
¶ A mixin to allow inline patching and automatic un-patching.
This mixin adds one new method,
create_patch
that will create and activate patch objects without having to use the decorator.In order to make use of the patching functionality you need to set the
patch_prefix
class attribute. This attribute should be the python module path whose objects you want to patch. For example, if you wanted to patch thebaz
object in thefoo.bar
module your patch prefix might look likefoo.bar
. When creating a patch you can now just refer to the object name likecls.create_patch('baz')
.This usage of this mixin as opposed to the patch decorator results in less pylint errors and not having to think about the order of decorator application.
Example Usage:
class MyTest(mixins.PatchMixin, bases.BaseTest): patch_prefix = 'my_application.module.submodule' @classmethod def configure(cls): cls.foo_mock = cls.create_patch('foo') cls.bar_mock = cls.create_patch('bar', return_value=100) @classmethod def execute(cls): function_under_test() def should_call_foo(self): self.foo_mock.assert_called_once_with() def should_return_100_from_bar(self): self.assertEqual(100, self.bar_mock.return_value)
-
classmethod
create_patch
(target, **kwargs)¶ Create and apply a patch.
This method calls
mock.patch()
with the keyword parameters and returns the running patch. This approach has the benefit of applying a patch without scoping the patched code which, in turn, lets you apply patches without having to overridesetUpClass()
to do it.Parameters: target (str) – the target of the patch. This is passed as an argument to cls.patch_prefix.format()
to create the fully-qualified patch target.
-
patch_prefix
= ''¶
-
classmethod
setUpClass
()¶
-
classmethod
stop_patches
()¶ Stop any active patches when the class is finished.
-
classmethod
tearDownClass
()¶
-
classmethod