Unit testing is an artwork. Whereas the query of what to check is essential (you may’t take a look at every little thing), on this publish we’ll take a more in-depth take a look at some superior testing and mocking methods in Python. Whereas a few of these had been already launched in earlier postings (Part 1, Part 2, Part 3), this publish differs by displaying their interaction on a real-world instance, in addition to goes above the scope of earlier posts and provides extra insights.
Amongst others, we’ll focus on:
- patching features — with the extra necessities of patching async features and modifying their behaviour
- asserting that features are referred to as as anticipated
- writing customized matchers for partially matching name arguments
Earlier than diving into the precise contents of this publish, we first give a fast recap of easy methods to use pytest. Afterwards, we do the identical for asyncio, since our instance additional on makes use of this. In case you are already aware of these subjects, please be at liberty to skip to the following part.
pytest
Unit testing must be a part of any considerably skilled software program product. It helps keep away from bugs and thus will increase effectivity and high quality of the code. Whereas Python natively ships with unittest, pytest is prefered by many builders.
To start, let’s take a look at one instance from a earlier publish:
import pytestclass MySummationClass:
def sum(self, x, y):
return x + y
@pytest.fixture
def my_summation_class():
return MySummationClass()
def test_sum(my_summation_class):
assert my_summation_class.sum(2, 3) == 5
We are able to run this take a look at through python -m pytest test_filename.py. When doing so, pytest discovers all exams in that file following some conventions (e.g. all features named test_…) and executes them. In our case, we outlined a fixture returning an occasion of MySummationClass. Fixtures can be utilized to e.g. keep away from repetitive initialisation and to moduralize code. We then name that occasion’s sum() methodology, and verify that the consequence equals the anticipated one through assert.
Mocking
Typically, throughout testing we encounter features we both can’t or don’t wish to run — e.g. as a result of they’d take too lengthy or have undesired uncomfortable side effects. For this goal, we will mock them out.
Let’s think about an instance from the earlier publish:
import time
from unittest.mock import Mock, patchdef expensive_function() -> int:
time.sleep(10)
return 42
def function_to_be_tested() -> int:
expensive_operation_result = expensive_function()
return expensive_operation_result * 2
@patch("sample_file_name.expensive_function")
def test_function_to_be_tested(mock_expensive_function: Mock) -> None:
mock_expensive_function.return_value = 42
assert function_to_be_tested() == 84
We’re utilizing a decorator to patch expensive_function with mock_expensive_function, this manner changing the unique perform’s long term time by a perform with related properties, chosen by us.
asyncio
Lastly, let’s briefly recap asyncio: asyncio is a multi-threading library whose main space of software is I/O sure functions — that’s functions, which spend a big portion of their time ready for inputs or outputs. asyncio really makes use of a single thread for this, and leaves it as much as the developer to outline when coroutines can yield execution and hand over to others.
Let’s re-use the motivating instance from the earlier publish:
import asyncioasync def sleepy_function():
print("Earlier than sleeping.")
await asyncio.sleep(1)
print("After sleeping.")
async def principal():
await asyncio.collect(*[sleepy_function() for _ in range(3)])
asyncio.run(principal())
If we had been to run sleepy_function conventionally 3 times in a row, this may take 3s. Nonetheless, with asyncio this program finishes in 1s: collect schedules the execution of three perform calls, and inside sleepy_function the key phrase await yields management again to the principle loop, which has time to execute different code (right here: different cases of sleepy_function) whereas sleeping for 1s.
Now, outfitted with adequate prior data, let’s dive deeper into the precise contents of this publish. Specifically, on this part we first outline the programming drawback serving as playground for unit testing.
For establishing the undertaking, we used poetry, and likewise adopted different best practises, comparable to utilizing typing, formatters and linters.
Our instance fashions producing some messages and sending them through some consumer (e.g. electronic mail): in the principle file, we first instantiate the consumer through a manufacturing unit perform, then generate some messages, and lastly ship these messages asynchronously utilizing the consumer.
The undertaking consists of the next information, which you may as well discover on github:
pyproject.toml
[tool.poetry]
identify = "Pytest Instance"
model = "0.1.0"
description = "A considerably bigger pytest instance"
authors = ["hermanmichaels <hrmnmichaels@gmail.com>"][tool.poetry.dependencies]
python = "3.10"
mypy = "0.910"
pytest = "7.1.2"
pytest-asyncio = "0.21.0"
black = "22.3.0"
flake8 = "4.0.1"
isort = "^5.10.1"
message_sending.py
import asynciofrom message_utils import Message, generate_message_client
def generate_messages() -> record[Message]:
return [Message("Message 1"), Message("Message 2")]
async def send_messages() -> None:
message_client = generate_message_client()
messages = generate_messages()
await asyncio.collect(*[message_client.send(message) for message in messages])
def principal() -> None:
asyncio.run(send_messages())
if __name__ == "__main__":
principal()
message_utils.py
from dataclasses import dataclass@dataclass
class Message:
physique: str
class MessageClient:
async def ship(self, message: Message) -> None:
print(f"Sending message: {message}")
def generate_message_client() -> MessageClient:
return MessageClient()
We are able to run this program through python message_sending.py, which — as said above — first instantiates a MessageClient, then generates a listing of dummy messages through generate_messages, and ultimately sends these utilizing asyncio. Within the final step, we create duties message_client.ship(message) for each message, after which run these asynchronously through collect.
With that, let’s come to testing. Right here, our objective is to create some eventualities, and to make sure that the proper messages are being ship out through the message consumer. Naturally, our easy demo setting is simply too simplistic to cowl this, however think about the next: in the actual, you’re utilizing the consumer to ship out messages to prospects. Relying on sure occasions (e.g. product purchased / offered), there might be completely different messages created. You thus wish to simulate these completely different eventualities (e.g. mock somebody shopping for a product), and verify, that the appropriate emails are being generated and despatched out.
Sending precise emails throughout testing might be not desired although: it could put stress on the e-mail server, and would require sure setup steps, comparable to getting into credentials, and many others. Thus, we wish to mock out the message consumer, particularly it’s ship perform. Through the take a look at we then merely put some expectations on this perform, and confirm it was referred to as as anticipated (e.g. with the appropriate messages). Right here, we is not going to mock generate_messages: whereas actually attainable (and desired in some unit exams), the thought right here is to not contact the message producing logic — whereas clearly very simplistic right here, in an actual system the messages can be generated based mostly on sure situations, which we wish to take a look at (one may thus name this extra of an integration take a look at, than an remoted unit take a look at).
Take a look at Perform was Known as As soon as
For a primary attempt, let’s change generate_messages to solely create a single message. Then, we anticipate the ship() perform to be referred to as as soon as, which we’ll take a look at right here.
That is how the corresponding take a look at seems to be:
from unittest.mock import AsyncMock, Mock, name, patchimport pytest as pytest
from message_sending import send_messages
from message_utils import Message
@pytest.fixture
def message_client_mock():
message_client_mock = Mock()
message_client_mock_send = AsyncMock()
message_client_mock.ship = message_client_mock_send
return message_client_mock
@pytest.mark.asyncio
@patch("message_sending.generate_message_client")
async def test_send_messages(
generate_message_client: Mock, message_client_mock: Mock
):
generate_message_client.return_value = message_client_mock
await send_messages()
message_client_mock.ship.assert_called_once()
Let’s dissect this in additional particulars: test_send_messages is our principal take a look at perform. We patched the perform generate_message_client, with a view to not use the actual (electronic mail) consumer returned within the authentic perform. Take note of “where to patch”: generate_message_client is outlined in message_utils, however since it’s imported through from message_utils import generate_message_client, we’ve got to focus on message_sending because the patch goal.
We’re not completed but although, because of asyncio. If we continued with out including extra particulars to the mocked message consumer, we might get an error just like the next:
TypeError: An asyncio.Future, a coroutine or an awaitable is required … ValueError(‘The long run belongs to a unique loop than ‘ ‘the one specified because the loop argument’).
The explanation for that is that in message_sending we name asyncio.collect on message_client.ship. Nonetheless, as of now, the mocked message consumer, and consequently its ship message, are merely Mock objects, which can’t be scheduled asynchronously. With a view to get round this, we launched the fixture message_client_mock. On this, we outline a Mock object referred to as message_client_mock, after which outline its ship methodology as an AsyncMock object. Then, we assign this as return_value to the generate_message_client perform.
Word that pytest natively really doesn’t help asyncio, however wants the package deal pytest-asyncio, which we put in within the pyproject.toml file.
Take a look at Perform was Known as As soon as With Particular Argument
As a subsequent step, we not solely wish to verify ship was referred to as as soon as, as anticipated — but additionally guarantee it was referred to as with the appropriate arguments — i.e. the appropriate message.
For this, we first overload the equals operator for Message:
def __eq__(self, different: object) -> bool:
if not isinstance(different, Message):
return NotImplemented
return self.physique == different.physique
Then, on the finish of the take a look at, we use the next expectation:
message_client_mock.ship.assert_called_once_with(Message("Message 1"))
Partially Matching Arguments
Typically, we’d wish to do some “fuzzy” matching — that’s, don’t verify for the precise arguments a perform was referred to as with, however verify some portion of them. To stick with our consumer story of sending emails: think about, the precise emails accommodates a lot of textual content, of which some is considerably arbitrary and particular (e.g. a date / time).
To do that, we implement a brand new proxy class, which implements the __eq__ operator w.r.t. Message. Right here, we merely subclass string, and verify it being contained in message.physique:
class MessageMatcher(str):
def __eq__(self, different: object):
if not isinstance(different, Message):
return NotImplemented
return self in different.physique
We are able to then assert that the despatched message e.g. accommodates a “1”:
message_client_mock.ship.assert_called_once_with(MessageMatcher("1"))
Checking Arguments for A number of Calls
Naturally, solely having the ability to verify {that a} perform was referred to as as soon as isn’t very useful. If we wish to verify a perform was referred to as N occasions with completely different arguments, we will use assert_has_calls. This expects a listing of of sort name, with every component describing one anticipated name:
message_client_mock.ship.assert_has_calls(
[call(Message("Message 1")), call(MessageMatcher("2"))]
)
This brings us to the top of this text. After recapping the fundamentals of pytest and asyncio, we dove right into a real-world instance and analysed some superior testing, and particularly mocking, methods.
We noticed easy methods to take a look at and mock async features, easy methods to assert they’re referred to as as anticipated, and easy methods to loosen up equality checks for the anticipated arguments.
I hope you loved studying this tutorial — thanks for tuning in!
