What you can generate and how¶

Most things should be easy to generate and everything should be possible.

To support this principle Hypothesis provides strategies for most built-in types with arguments to constrain or adjust the output, as well as higher-order strategies that can be composed to generate more complex types.

This document is a guide to what strategies are available for generating data and how to build them. Strategies have a variety of other important internal features, such as how they simplify, but the data they can generate is the only public part of their API.

Provisional strategies¶ This module contains various provisional APIs and strategies. It is intended for internal use, to ease code reuse, and is not stable. Point releases may move or break the contents at any time! Internet strategies should conform to RFC 3986 or the authoritative definitions it links to. If not, report the bug! hypothesis.provisional. domains ( * , max_length = 255 , max_element_length = 63 ) [source] ¶ Generate RFC 1035 compliant fully qualified domain names. hypothesis.provisional. urls ( ) [source] ¶ A strategy for RFC 3986, generating http/https URLs.

Shrinking¶ When using strategies it is worth thinking about how the data shrinks. Shrinking is the process by which Hypothesis tries to produce human readable examples when it finds a failure - it takes a complex example and turns it into a simpler one. Each strategy defines an order in which it shrinks - you won’t usually need to care about this much, but it can be worth being aware of as it can affect what the best way to write your own strategies is. The exact shrinking behaviour is not a guaranteed part of the API, but it doesn’t change that often and when it does it’s usually because we think the new way produces nicer examples. Possibly the most important one to be aware of is one_of() , which has a preference for values produced by strategies earlier in its argument list. Most of the others should largely “do the right thing” without you having to think about it.

Adapting strategies¶ Often it is the case that a strategy doesn’t produce exactly what you want it to and you need to adapt it. Sometimes you can do this in the test, but this hurts reuse because you then have to repeat the adaption in every test. Hypothesis gives you ways to build strategies from other strategies given functions for transforming the data. Mapping¶ map is probably the easiest and most useful of these to use. If you have a strategy s and a function f , then an example s.map(f).example() is f(s.example()) , i.e. we draw an example from s and then apply f to it. e.g.: >>> lists ( integers ()) . map ( sorted ) . example () [-25527, -24245, -23118, -93, -70, -7, 0, 39, 40, 65, 88, 112, 6189, 9480, 19469, 27256, 32526, 1566924430] Note that many things that you might use mapping for can also be done with builds() . Filtering¶ filter lets you reject some examples. s.filter(f).example() is some example of s such that f(example) is truthy. >>> integers () . filter ( lambda x : x > 11 ) . example () 26126 >>> integers () . filter ( lambda x : x > 11 ) . example () 23324 It’s important to note that filter isn’t magic and if your condition is too hard to satisfy then this can fail: >>> integers () . filter ( lambda x : False ) . example () Traceback (most recent call last): ... hypothesis.errors.Unsatisfiable : Could not find any valid examples in 20 tries In general you should try to use filter only to avoid corner cases that you don’t want rather than attempting to cut out a large chunk of the search space. A technique that often works well here is to use map to first transform the data and then use filter to remove things that didn’t work out. So for example if you wanted pairs of integers (x,y) such that x < y you could do the following: >>> tuples ( integers (), integers ()) . map ( sorted ) . filter ( lambda x : x [ 0 ] < x [ 1 ]) . example () [-8543729478746591815, 3760495307320535691] Chaining strategies together¶ Finally there is flatmap . flatmap draws an example, then turns that example into a strategy, then draws an example from that strategy. It may not be obvious why you want this at first, but it turns out to be quite useful because it lets you generate different types of data with relationships to each other. For example suppose we wanted to generate a list of lists of the same length: >>> rectangle_lists = integers ( min_value = 0 , max_value = 10 ) . flatmap ( ... lambda n : lists ( lists ( integers (), min_size = n , max_size = n ))) >>> rectangle_lists . example () [] >>> rectangle_lists . filter ( lambda x : len ( x ) >= 10 ) . example () [[], [], [], [], [], [], [], [], [], []] >>> rectangle_lists . filter ( lambda t : len ( t ) >= 3 and len ( t [ 0 ]) >= 3 ) . example () [[0, 0, 0], [0, 0, 0], [0, 0, 0]] >>> rectangle_lists . filter ( lambda t : sum ( len ( s ) for s in t ) >= 10 ) . example () [[0], [0], [0], [0], [0], [0], [0], [0], [0], [0]] In this example we first choose a length for our tuples, then we build a strategy which generates lists containing lists precisely of that length. The finds show what simple examples for this look like. Most of the time you probably don’t want flatmap , but unlike filter and map which are just conveniences for things you could just do in your tests, flatmap allows genuinely new data generation that you wouldn’t otherwise be able to easily do. (If you know Haskell: Yes, this is more or less a monadic bind. If you don’t know Haskell, ignore everything in these parentheses. You do not need to understand anything about monads to use this, or anything else in Hypothesis). Recursive data¶ Sometimes the data you want to generate has a recursive definition. e.g. if you wanted to generate JSON data, valid JSON is: Any float, any boolean, any unicode string. Any list of valid JSON data Any dictionary mapping unicode strings to valid JSON data. The problem is that you cannot call a strategy recursively and expect it to not just blow up and eat all your memory. The other problem here is that not all unicode strings display consistently on different machines, so we’ll restrict them in our doctest. The way Hypothesis handles this is with the recursive() strategy which you pass in a base case and a function that, given a strategy for your data type, returns a new strategy for it. So for example: >>> from string import printable ; from pprint import pprint >>> json = recursive ( none () | booleans () | floats () | text ( printable ), ... lambda children : lists ( children , 1 ) | dictionaries ( text ( printable ), children , min_size = 1 )) >>> pprint ( json . example ()) [[1.175494351e-38, ']', 1.9, True, False, '.M}Xl', ''], True] >>> pprint ( json . example ()) {'de(l': None, 'nK': {'(Rt)': None, '+hoZh1YU]gy8': True, '8z]EIFA06^l`i^': 'LFE{Q', '9,': 'l{cA=/'}} That is, we start with our leaf data and then we augment it by allowing lists and dictionaries of anything we can generate as JSON data. The size control of this works by limiting the maximum number of values that can be drawn from the base strategy. So for example if we wanted to only generate really small JSON we could do this as: >>> small_lists = recursive ( booleans (), lists , max_leaves = 5 ) >>> small_lists . example () True >>> small_lists . example () [False]

Composite strategies¶ The @composite decorator lets you combine other strategies in more or less arbitrary ways. It’s probably the main thing you’ll want to use for complicated custom strategies. The composite decorator works by converting a function that returns one example into a function that returns a strategy that produces such examples - which you can pass to @given , modify with .map or .filter , and generally use like any other strategy. It does this by giving you a special function draw as the first argument, which can be used just like the corresponding method of the data() strategy within a test. In fact, the implementation is almost the same - but defining a strategy with @composite makes code reuse easier, and usually improves the display of failing examples. For example, the following gives you a list and an index into it: >>> @composite ... def list_and_index ( draw , elements = integers ()): ... xs = draw ( lists ( elements , min_size = 1 )) ... i = draw ( integers ( min_value = 0 , max_value = len ( xs ) - 1 )) ... return ( xs , i ) draw(s) is a function that should be thought of as returning s.example() , except that the result is reproducible and will minimize correctly. The decorated function has the initial argument removed from the list, but will accept all the others in the expected order. Defaults are preserved. >>> list_and_index () list_and_index() >>> list_and_index () . example () ([15949, -35, 21764, 8167, 1607867656, -41, 104, 19, -90, 520116744169390387, 7107438879249457973], 0) >>> list_and_index ( booleans ()) list_and_index(elements=booleans()) >>> list_and_index ( booleans ()) . example () ([True, False], 0) Note that the repr will work exactly like it does for all the built-in strategies: it will be a function that you can call to get the strategy in question, with values provided only if they do not match the defaults. You can use assume inside composite functions: @composite def distinct_strings_with_common_characters ( draw ): x = draw ( text ( min_size = 1 )) y = draw ( text ( alphabet = x )) assume ( x != y ) return ( x , y ) This works as assume normally would, filtering out any examples for which the passed in argument is falsey. Take care that your function can cope with adversarial draws, or explicitly rejects them using the .filter() method or assume() - our mutation and shrinking logic can do some strange things, and a naive implementation might lead to serious performance problems. For example: @composite def reimplementing_sets_strategy ( draw , elements = st . integers (), size = 5 ): # The bad way: if Hypothesis keeps generating e.g. zero, # we'll keep looping for a very long time. result = set () while len ( result ) < size : result . add ( draw ( elements )) # The good way: use a filter, so Hypothesis can tell what's valid! for _ in range ( size ): result . add ( draw ( elements . filter ( lambda x : x not in result ))) return result