A simple wrapper around the unittest package with different styles for specs
Project description
unittest_specs
Table of content
FunSpec
This style can be used to write highly readable test cases helpful for good documentation in code.
Due to its limitations, this style is mostly suited for compact unit tests, since no elaborate test structure can be written.
Usage
FunSpec provides the three functions describe(), it() and expect() to construct RSpec inspired test cases,
which might feel more familiar to e.g. TypeScript developers. Specifications written this way are picked up by
unittest's auto-discovery (python3 -m unittest <directory>), since they are converted into unittest.TestCase
sub-classes and are therefore valid unittest tests.
Setting up test cases is pretty straight forward:
from unittest_specs import describe, it, expect
describe("Python numbers",
it("5 should be of type int",
expect(5).to_be_of_type(int)
)
)
Above example dynamically creates a type equivalent to:
import unittest
class PythonNumbers(unittest.TestCase):
def test_5_should_be_of_type_int(self):
self.assertIsInstance(5, int)
The constructed type is hooked into the executing module (the one calling describe()), so that unittest
picks it up while performing its auto-discovery.
For every describe() block an arbitrary amount of it() statements can be defined, with each resulting in a
separate test function. Keep in mind that each it() should have a description unique to its describe() block
(see Limitations for further detail). This might look something like this:
from unittest_specs import describe, it, expect
describe("Python arithmatic",
it("should multiply correctly",
expect(2 * 5).to_be(10)
),
it("should square correctly",
expect(4 ** 2).to_be(16)
),
it("should subtract correctly",
expect(1340 - 3).to_be(1337)
),
)
Which, again, translates to an equivalent of:
import unittest
class PythonArithmatic(unittest.TestCase):
def test_should_multiply_correctly(self):
self.assertEqual(2 * 5, 10)
def test_should_square_correctly(self):
self.assertEqual(4 ** 2, 16)
def test_should_subtract_correctly(self):
self.assertEqual(1340 - 3, 1337)
Limitations
Descriptions and Identifiers
The descriptions provided in describe() and it() are used to dynamically generate test classes based on
unittest.TestCase, with the description specified in describe() being converted into the class name and all
following it() descriptions being used for test function names. Since both are identifiers, which Python requires
to be unique in their appropriate context, some unexpected behaviour might occur when violating this requirement.
it() and Blocks
As of now, there is no way to specify anonymous blocks in Python syntax. This means that, unfortunately, in the
current implementation, every test case specified in it() needs to only consist of one single evaluation.
Therefore, the recommended usage is to utilize expect() and its assertions to formulate the test.
SimpleFlatSpec
The simple flat spec style is visually very close to plain unittest.TestCase code and can, in fact be used
as a drop-in replacement. Its main advantage is a set of more readable assertions, as well as some utility
decorators.
Usage
The SimpleFlatSpec class provides an easy and readable way to write tests. Much like in
unittest itself, each test case should be specified in a separate test function with a name
outlining the expected behaviour. In the function body, any required setup can be performed, before
calling self.expect() to provide the computed actual value. This declaration should be followed by
an assertion, of which there is a range to choose from (see the following section for a complete list).
A very simple test case could look something like this:
from unittest_specs import SimpleFlatSpec
class MyTest(SimpleFlatSpec):
def test_should_identify_even_number(self):
is_even_number = 4 % 2 == 0
self.expect(is_even_number).to_be_true()
Available Assertions
| Assertion Function | Description | Equivalent unittest function |
|---|---|---|
to_be() |
checks for equality between actual and expected value | assertEqual() |
to_not_be() |
checks for inequality between actual and expected value | assertNotEqual() |
to_be_of_type() |
checks whether the actual value is of a specified type | assertIsInstance() |
to_equal_list() |
checks an actual and expected list for equality | assertListEqual() |
to_contain() |
checks whether the actual collection contains an expected value | assertTrue(expected_element in self._actual_value) |
to_contain_all() |
checks whether the actual collection contains all expected values | custom implementation |
to_be_true() |
checks whether the actual value is of value True |
assertTrue() |
to_be_false() |
checks whether the actual value is of value False |
assertFalse() |
to_be_none() |
checks whether the actual value is None |
assertIsNone() |
to_not_be_none() |
checks whether the actual value is not None |
assertIsNotNone() |
to_be_a_list() |
checks whether the actual value is of type list |
assertIsInstance(actual_value, list) |
to_be_a_dict() |
checks whether the actual value is of type dict |
assertIsInstance(actual_value, dict) |
to_be_a_set() |
checks whether the actual value is of type set |
assertIsInstance(actual_value, set) |
to_raise() |
intercepts an Exception expected to be raised in the test function |
assertRaises() |
to_be_of_length() |
checks for an expected length of an object supporting len() | assertEqual(len(actual_value), expected_value) |
Parameterizing Tests
Instead of writing several test function covering the same functionality with different parameters, one can use
parameterization to provide an arbitrarily long list of test data sets. This is implemented using the unittest.TestCase.subTest
function, with the first element in each being used as the label.
A parameterized test might look like the following:
from unittest_specs import SimpleFlatSpec
class MyTest(SimpleFlatSpec):
@SimpleFlatSpec.parameterize(params=[
('hello', 5),
('world!', 6),
])
def test_should_check_string_length(self, given_string, expected_length):
self.expect(given_string).to_be_of_length(expected_length)
Project details
Release history Release notifications | RSS feed
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
Source Distribution
Built Distribution
Filter files by name, interpreter, ABI, and platform.
If you're not sure about the file name format, learn more about wheel file names.
Copy a direct link to the current filters
File details
Details for the file unittest-specs-1.1.0.tar.gz.
File metadata
- Download URL: unittest-specs-1.1.0.tar.gz
- Upload date:
- Size: 10.1 kB
- Tags: Source
- Uploaded using Trusted Publishing? No
- Uploaded via: twine/4.0.0 CPython/3.8.10
File hashes
| Algorithm | Hash digest | |
|---|---|---|
| SHA256 |
18fb334bb8c041a0b2c598df1559e58da46719cf4dd6042ba51c4e312dd08265
|
|
| MD5 |
d395c2f927ae43fa96c4578a7739bb74
|
|
| BLAKE2b-256 |
3126103700708b48f1b762b8aafa2ca8d1828bc87a489044765b794121048a73
|
File details
Details for the file unittest_specs-1.1.0-py3-none-any.whl.
File metadata
- Download URL: unittest_specs-1.1.0-py3-none-any.whl
- Upload date:
- Size: 9.3 kB
- Tags: Python 3
- Uploaded using Trusted Publishing? No
- Uploaded via: twine/4.0.0 CPython/3.8.10
File hashes
| Algorithm | Hash digest | |
|---|---|---|
| SHA256 |
8882065749c4a7057b2be7e3bdebc8f178a4484a63757006e2e13aaed2c8f0b2
|
|
| MD5 |
53444edd41897a9e5744fca5d95822db
|
|
| BLAKE2b-256 |
b328b06cb672de8144e8c3393ddce5b6d7e61affbfcff6ff605d405b33827e16
|