Additional packages

Hypothesis itself does not have any dependencies, but there are some packages that need additional things installed in order to work.

You can install these dependencies using the setuptools extra feature as e.g. pip install hypothesis[django]. This will check installation of compatible versions.

You can also just install hypothesis into a project using them, ignore the version constraints, and hope for the best.

In general “Which version is Hypothesis compatible with?” is a hard question to answer and even harder to regularly test. Hypothesis is always tested against the latest compatible version and each package will note the expected compatibility range. If you run into a bug with any of these please specify the dependency version.

There are separate pages for Hypothesis for Django users and Hypothesis for the Scientific Stack.


This module provides tools for working with the dpcontracts library, because combining contracts and property-based testing works really well.

It requires dpcontracts >= 0.4.


Decorate contract_func to reject calls which violate preconditions, and retry them with different arguments.

This is a convenience function for testing internal code that uses :pypi:dpcontracts`, to automatically filter out arguments that would be rejected by the public interface before triggering a contract error.

This can be used as builds(fulfill(func), ...) or in the body of the test e.g. assert fulfill(func)(*args).


This module provides pytz timezones.

You can use this strategy to make hypothesis.strategies.datetimes() and hypothesis.strategies.times() produce timezone-aware values.


Any timezone in the Olsen database, as a pytz tzinfo object.

This strategy minimises to UTC, or the smallest possible fixed offset, and is designed for use with hypothesis.strategies.datetimes().


This module provides dateutil timezones.

You can use this strategy to make hypothesis.strategies.datetimes() and hypothesis.strategies.times() produce timezone-aware values.


Any timezone in dateutil.

This strategy minimises to UTC, or the timezone with the smallest offset from UTC as of 2000-01-01, and is designed for use with datetimes().

Note that the timezones generated by the strategy may vary depending on the configuration of your machine. See the dateutil documentation for more information.


This module provides deprecated time and date related strategies.

It depends on the pytz package, which is stable enough that almost any version should be compatible - most updates are for the timezone database.

hypothesis.extra.datetime.datetimes(allow_naive=None, timezones=None, min_year=None, max_year=None)[source]

Return a strategy for generating datetimes.

Deprecated since version 3.9.0: use hypothesis.strategies.datetimes() instead.

allow_naive=True will cause the values to sometimes be naive. timezones is the set of permissible timezones. If set to an empty collection all datetimes will be naive. If set to None all timezones available via pytz will be used.

All generated datetimes will be between min_year and max_year, inclusive.

hypothesis.extra.datetime.dates(min_year=None, max_year=None)[source]

Return a strategy for generating dates.

Deprecated since version 3.9.0: use hypothesis.strategies.dates() instead.

All generated dates will be between min_year and max_year, inclusive.

hypothesis.extra.datetime.times(allow_naive=None, timezones=None)[source]

Return a strategy for generating times.

Deprecated since version 3.9.0: use hypothesis.strategies.times() instead.

The allow_naive and timezones arguments act the same as the datetimes strategy above.



This extra package is deprecated. We strongly recommend using native Hypothesis strategies, which are more effective at both finding and shrinking failing examples for your tests.

The from_regex(), emails(), text() (with some specific alphabet), and sampled_from() strategies may be particularly useful.

Faker (previously fake-factory) is a Python package that generates fake data for you. It’s great for bootstraping your database, creating good-looking XML documents, stress-testing a database, or anonymizing production data. However, it’s not designed for automated testing - data from Hypothesis looks less realistic, but produces minimal bug-triggering examples and uses coverage information to check more cases.

hypothesis.extra.fakefactory lets you use Faker generators to parametrize Hypothesis tests. This was only ever meant to ease your transition to Hypothesis, but we’ve improved Hypothesis enough since then that we no longer recommend using Faker for automated tests under any circumstances.

hypothesis.extra.fakefactory defines a function fake_factory which returns a strategy for producing text data from any Faker provider.

So for example the following will parametrize a test by an email address:

>>> fake_factory('email').example()

>>> fake_factory('name').example()
'Zbyněk Černý CSc.'

You can explicitly specify the locale (otherwise it uses any of the available locales), either as a single locale or as several:

>>> fake_factory('name', locale='en_GB').example()
'Antione Gerlach'
>>> fake_factory('name', locales=['en_GB', 'cs_CZ']).example()
'Miloš Šťastný'
>>> fake_factory('name', locales=['en_GB', 'cs_CZ']).example()
'Harm Sanford'

You can use custom Faker providers via the providers argument:

>>> from faker.providers import BaseProvider
>>> class KittenProvider(BaseProvider):
...     def meows(self):
...         return 'meow %d' % (self.random_number(digits=10),)
>>> fake_factory('meows', providers=[KittenProvider]).example()
'meow 9139348419'