Skip to main content
Join the official 2020 Python Developers SurveyStart the survey!

A library that makes writing pyhamcrest matchers easier and more fun.

Project description Documentation Status Maintainability PyPI Package monthly downloads

PyHamcrest Toolbox

PyHamcrest is a great thing for writing reusable tests, but sometimes writing your own matchers may be a bit of a chore. This project aims at making this task easy, fast and even fun (for want of a better word).

To reiterate the obvious, a test should always do all the checks it has to do, and even if some of them fail, the rest should still be run. That way you will get a better idea of what’s gone wrong with your code, and you will waste less time fixing the first of the checks only to find the the second one is still failing, and that means that you should have fixed the first one in a different way.

So, instead of this:

def test_the_holy_grail():
    the_holy_grail = seek_the_holy_grail()
    assert_that(the_holy_grail.is_holy(), is_(True))
    assert_that(the_holy_grail.depth, greater_than(5))
    assert_that(the_holy_grail.width, greater_than(6))
    assert_that(the_holy_grail.height, greater_than(7))

this should be written as:

def test_the_holy_grail():
    the_holy_grail = seek_the_holy_grail()


def test_the_holy_grail():
    the_holy_grail = seek_the_holy_grail()
        grail(holy=True, width=5))

Both these examples, however, require writing your own matchers. With this toolbox, it is easy.


The MulticomponentMatcher allows writing the chain-style matchers.

All you have to do is to write your is_holy matcher that inherits from the MulticomponentMatcher as the backbone. Then you write individual matchers for each of the holy grail properties enhancing them with the MatcherPlugin, and you register them with the is_holy matcher.

So, this is your is_holy matcher:

class IsHolyMatcher(MulticomponentMatcher):
    def __init__(self):

def is_holy():
    return IsHolyMatcher()

And that’s it. You don’t have to override the usual matcher methods. Everything will be done by the parent class. However, it doesn’t do any matching yet, so we need to write the plugins. Let’s start with the actual holiness:

class HolinessMatcher(MatcherPlugin):
    def __init__(is_holy=True):
        self.is_holy = is_holy

    def component_matches(self, item):
        # the item will be a grail
        return self.is_holy == item.is_holy()

    def describe_to(self, description):
            "A grail which is {}holy".format("" if self.is_holy else "not "))

    def describe_component_mismatch(self, item, mismatch_description):
            "The grail was {}holy".format("" if item.is_holy() else "not "))

And then you register it with the main matcher:

class IsHolyMatcher(MulticomponentMatcher):
    def __init__(self, is_holy):

def holy(is_holy):
    return IsHolyMatcher(is_holy)

Of course, you could write that HolinessMatcher logic in your IsHolyMatcher, but if we have the power of plugins, then why not use it?

For now, we only have this bit: assert_that(the_grail, is_holy()), and not the .with_width(...) stuff. So let’s write it. I won’t go through the process of writing the plugin for the width as it is rather straightforward, but here’s how you register it with the main matcher:

class IsHolyMatcher(MulticomponentMatcher):
    def __init__(self, is_holy):

    def with_width(self, value):
        return self.register(GrailWidthMatcher(value))

def holy(is_holy):
    return IsHolyMatcher(is_holy)

Now you can do the is_holy().with_width(greater_than(5)) stuff. Note that you have to return self.register(...) from the plugin registering methods, as (a) you might want to chain them, and (b) the result of the chain still needs to be a matcher.


This matcher allows writing the kwarg-style matchers (as in the second example above), which are more pythonic, but look kind of unnatural when you want to match against another matcher instead of a plain value. I will show what I mean in a minute.

The general approach is the same as with the multicomponent matcher: you write matcher plugins for your components, and then you register them with your main matcher:

class GrailMatcher(KwargMulticomponentMatcher):
    def __init__(self, holy=None, width=None):
        self.register_for_kwarg(HolinessMatcher(holy), holy)
        self.register_for_kwarg(GrailWidthMatcher(width), width)

And then in your tests you do:

def test_correct_width_wrong_holiness(self, my_grail):
        grail(holy=True, width=4))

As I said before, this looks more pythonic, however, if you want to check your values against matchers, and not just plain values (like width=4 here), your code starts looking a bit strange:

def test_correct_width_wrong_holiness(self, my_grail):
        grail(holy=True, width=greater_than(4)))

My recommendation is to use the chain-style matchers if you know that your main matcher might be used this way.


You can find the demos for both approaches in the demo folder of this repo. Clone it, install the requirements from demo/requirements.txt, and run pytest demo/test_*

Project details

Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Files for pyhamcrest-toolbox, version 0.3.0
Filename, size File type Python version Upload date Hashes
Filename, size pyhamcrest_toolbox-0.3.0-py3-none-any.whl (7.7 kB) File type Wheel Python version py3 Upload date Hashes View
Filename, size pyhamcrest_toolbox-0.3.0.tar.gz (6.0 kB) File type Source Python version None Upload date Hashes View

Supported by

Pingdom Pingdom Monitoring Google Google Object Storage and Download Analytics Sentry Sentry Error logging AWS AWS Cloud computing DataDog DataDog Monitoring Fastly Fastly CDN DigiCert DigiCert EV certificate StatusPage StatusPage Status page