PyHamcrest Tutorial


PyHamcrest is a framework for writing matcher objects, allowing you to declaratively define “match” rules. There are a number of situations where matchers are invaluable, such as UI validation, or data filtering, but it is in the area of writing flexible tests that matchers are most commonly used. This tutorial shows you how to use PyHamcrest for unit testing.

When writing tests it is sometimes difficult to get the balance right between overspecifying the test (and making it brittle to changes), and not specifying enough (making the test less valuable since it continues to pass even when the thing being tested is broken). Having a tool that allows you to pick out precisely the aspect under test and describe the values it should have, to a controlled level of precision, helps greatly in writing tests that are “just right.” Such tests fail when the behavior of the aspect under test deviates from the expected behavior, yet continue to pass when minor, unrelated changes to the behaviour are made.

My first PyHamcrest test

We’ll start by writing a very simple PyUnit test, but instead of using PyUnit’s assertEqual method, we’ll use PyHamcrest’s assert_that construct and the standard set of matchers:

from hamcrest import assert_that, equal_to
import unittest

class BiscuitTest(unittest.TestCase):
    def testEquals(self):
        theBiscuit = Biscuit('Ginger')
        myBiscuit = Biscuit('Ginger')
        assert_that(theBiscuit, equal_to(myBiscuit))

if __name__ == '__main__':

The assert_that function is a stylized sentence for making a test assertion. In this example, the subject of the assertion is the object theBiscuit, which is the first method parameter. The second method parameter is a matcher for Biscuit objects, here a matcher that checks one object is equal to another using the Python == operator. The test passes since the Biscuit class defines an __eq__ method.

If you have more than one assertion in your test you can include an identifier for the tested value in the assertion:

assert_that(theBiscuit.getChocolateChipCount(), equal_to(10), 'chocolate chips')
assert_that(theBiscuit.getHazelnutCount(), equal_to(3), 'hazelnuts')

As a convenience, assert_that can also be used to verify a boolean condition:

assert_that(theBiscuit.isCooked(), 'cooked')

This is equivalent to the assert_ method of unittest.TestCase, but because it’s a standalone function, it offers greater flexibility in test writing.

Asserting Exceptions

There’s a utility function and matcher available to help you test that your code has the expected behavior in situations where it should raise an exception. The calling function wraps a callable, and then allows you to set arguments to be used in a call to the wrapped callable. This, together with the raises matcher lets you assert that calling a method with certain arguments causes an exception to be thrown. It is also possible to provide a regular expression pattern to the raises matcher allowing you assure that the right issue was found:

assert_that(calling(parse, bad_data), raises(ValueError))

assert_that(calling(translate).with_args(curse_words), raises(LanguageError, "\w+very naughty"))

assert_that(broken_function, raises(Exception))

# This will fail and complain that 23 is not callable
# assert_that(23, raises(IOError))

Asserting exceptions from async methods

An async method does not directly return the result or raise an exception but instead returns a Future-object that represent the async operation that can later be resolved with the await keyword. The resolved utility function can be used to wait for a future to be done but without retrieving the value or raising the exception. The future_raising matcher can be used with any future object but combined lets you assert that calling some async method, and waiting for the result, causes an exception to be raised.

This is best used together with an async test runner like IsolatedAsyncioTestCase or pytest-asyncio:

async def parse(input: str):

class Test(unittest.IsolatedAsyncioTestCase):

    async def testParse(self):
        future = parse("some bad data")
        assert_that(await resolved(future), future_raising(ValueError))

But it’s possible to use with an async unware runner by explicitly running the event loop in the test:

class Test(unittest.TestCase):
    def test_parse(self):
        async def test():
            future = parse("some bad data")
            assert_that(await resolved(future), future_raising(ValueError))


Predefined matchers

PyHamcrest comes with a library of useful matchers:

The arguments for many of these matchers accept not just a matching value, but another matcher, so matchers can be composed for greater flexibility. For example, only_contains(less_than(5)) will match any sequence where every item is less than 5.

Syntactic sugar

PyHamcrest strives to make your tests as readable as possible. For example, the is_ matcher is a wrapper that doesn’t add any extra behavior to the underlying matcher. The following assertions are all equivalent:

assert_that(theBiscuit, equal_to(myBiscuit))
assert_that(theBiscuit, is_(equal_to(myBiscuit)))
assert_that(theBiscuit, is_(myBiscuit))

The last form is allowed since is_(value) wraps most non-matcher arguments with equal_to. But if the argument is a type, it is wrapped with instance_of, so the following are also equivalent:

assert_that(theBiscuit, instance_of(Biscuit))
assert_that(theBiscuit, is_(instance_of(Biscuit)))
assert_that(theBiscuit, is_(Biscuit))

(Note that PyHamcrest’s is_ matcher is unrelated to Python’s is operator. The matcher for object identity is same_instance.)