Skip to content

Releases: HypothesisWorks/hypothesis

Hypothesis for Python - version 6.65.2

27 Jan 10:09
Compare
Choose a tag to compare

This patch fixes invalid annotations detected for the tests generated
by Ghostwritter. It will now correctly generate "Optional" types with
just one type argument and handle union expressions inside of type
arguments correctly. Additionally, it now supports code with the "from
future import annotations" marker for Python 3.10 and newer.

The canonical version of these notes (with links) is on readthedocs.

Hypothesis for Python - version 6.65.1

26 Jan 14:46
Compare
Choose a tag to compare

This release improves the pretty-printing of enums in falsifying
examples, so that they print as their full identifier rather than
their repr.

The canonical version of these notes (with links) is on readthedocs.

Hypothesis for Python - version 6.65.0

24 Jan 10:50
Compare
Choose a tag to compare

Hypothesis now reports some failing inputs by showing the call which
constructed an object, rather than the repr of the object. This can
be helpful when the default repr does not include all relevant
details, and will unlock further improvements in a future version.

For now, we capture calls made via "builds()", and via
SearchStrategy.map().

The canonical version of these notes (with links) is on readthedocs.

Hypothesis for Python - version 6.64.0

23 Jan 01:07
Compare
Choose a tag to compare

The Ghostwritter will now include type annotations on tests for type-
annotated code. If you want to force this to happen (or not happen),
pass a boolean to the new "annotate=" argument to the Python
functions, or the "--[no-]annotate" CLI flag.

Thanks to Nicolas Ganz for this new feature!

The canonical version of these notes (with links) is on readthedocs.

Hypothesis for Python - version 6.63.0

20 Jan 14:46
Compare
Choose a tag to compare

"range_indexes()" now accepts a "name=" argument, to generate named
"pandas.RangeIndex" objects.

Thanks to Sam Watts for this new feature!

The canonical version of these notes (with links) is on readthedocs.

Hypothesis for Python - version 6.62.1

14 Jan 12:33
Compare
Choose a tag to compare

This patch tweaks "xps.arrays()" internals to improve PyTorch
compatibility. Specifically, "torch.full()" does not accept integers
as the shape argument (n.b. technically "size" in torch), but such
behaviour is expected in internal code, so we copy the "torch" module
and patch in a working "full()" function.

The canonical version of these notes (with links) is on readthedocs.

Hypothesis for Python - version 6.62.0

08 Jan 18:03
Compare
Choose a tag to compare

A classic error when testing is to write a test function that can
never fail, even on inputs that aren't allowed or manually provided.
By analogy to the design pattern of:

@pytest.mark.parametrize("arg", [
..., # passing examples
pytest.param(..., marks=[pytest.mark.xfail]) # expected-failing input
])

we now support "@example(...).xfail()", with the same (optional)
"condition", "reason", and "raises" arguments as
"pytest.mark.xfail()".

Naturally you can also write ".via(...).xfail(...)", or
".xfail(...).via(...)", if you wish to note the provenance of
expected-failing examples.

The canonical version of these notes (with links) is on readthedocs.

Hypothesis for Python - version 6.61.3

08 Jan 00:34
Compare
Choose a tag to compare

This patch teaches our enhanced "get_type_hints()" function to 'see
through' "partial" application, allowing inference from type hints to
work in a few more cases which aren't (yet!) supported by the
standard-library version.

The canonical version of these notes (with links) is on readthedocs.

Hypothesis for Python - version 6.61.2

07 Jan 10:48
Compare
Choose a tag to compare

This patch improves our pretty-printing of failing examples, including
some refactoring to prepare for exciting future features.

The canonical version of these notes (with links) is on readthedocs.

Hypothesis for Python - version 6.61.1

06 Jan 16:37
Compare
Choose a tag to compare

This patch brings our "domains()" and "emails()" strategies into
compliance with RFC 5890 §2.3.1: we no longer generate parts-of-
domains where the third and fourth characters are "--" ("R-LDH
labels"), though future versions may deliberately generate "xn--"
punycode labels. Thanks to python-email-validator for the report!

The canonical version of these notes (with links) is on readthedocs.