Если никогда не слышали о hypothesis и хотите дополнить свои функциональные интеграционные тесты чем-то новым и попробовать найти баги там, где вроде бы уже искали – добро пожаловать в статью.  Эта библиотека позволяет параметризовать тестовую функцию случайными (но не совсем) параметрами и таким образом находить хитрые баги. Пример использования из документации: st.integers() – это так называемая “стратегия” в терминах hypothesis, которая говорит о том, что в качестве параметров x, y будут числа. А какие именно – выберет сам hypothesis. Чтобы уменьшить количество генерируемых кейсов и убрать совсем странные варианты в стратегию можно также передавать параметры и контролировать какие именно числа надо использовать. Т.е. можно, например, указать мин/макс значения: По мимо чисел, в качестве параметров можно передавать почти все что угодно - стратегии есть на все случаи жизни, примеры здесь. Для них обычно требуется хранить состояние системы и проверять не работу одного конкретного метода с разными параметрами, а всю систему целиком. Для начала, давайте представим, что мы разрабатываем структуру данных – словарь и хотим её по-всякому протестировать. Нас прежде всего интересуют методы - добавить значение по ключу, получить значение по ключу и получить размер словаря. Теперь вернемся обратно к hypothesis. В этой библиотеке есть прекрасная вещь под названием - Rule-based state machine. По сути, это класс, который представляет собой конечный автомат, который эмулирует тестируемую систему. Методы класса являются переходами между состояниями системы, а само состояние хранится в переменных класса типа Bundle и в переменной self. Методы-переходы вызываются в случайном порядке и в случайном количестве. Но порядок вызовов можно регулировать с помощью переменных класса типа Bundle и с помощью декоратора @precondition. Обозначение метода-перехода происходит через декоратор @rule: У @rule есть важный параметр – target, он обозначает, куда будет сохраняться значение, возвращаемое методом-переходом. В данном случае, мы сохраняем возвращаемый ключ в переменную класса keys. Два других параметра – key и value, по аналогии с примером в начале статьи, являются входными параметрами уже для самого метода-перехода. Их непосредственные значения определяются стратегиями text() и integers().  Про @precondition - в нем мы указываем функцию, которая будет вызываться до вызова метода-перехода и определит будет ли этот метод-переход вызван или нет. В примере – перед вызовом метода мы удостоверяемся, что тестируемый словарь существует. Если нет – этот метод вызываться не будет. Если необходимо убрать значение из переменной типа Bundle, используется метод consumes: Ключ на вход поступает из переменной класса keys. После вызова метода – полученный ключ удаляется из переменной keys. Если не использовать consumes – ключ не удалится и методы remove_element и add_element могут быть вызваны повторно с уже удаленным ключом.  Есть еще один декоратор, который может пригодиться – @invariant Он вызывается каждый раз до и после вызовов методов-переходов и проверяет, что некое утверждение о состоянии системы все еще верно.  И еще одна важная вещь – метод teardown: Вызывается по окончании каждого кейса и позволяет почистить за собой. По мимо всего этого, нужно как-то регулировать количество кейсов и количество переходов в рамках конкретных кейсов, которые сгенерирует hypothesis. Для этого есть вот такие настройки: Вызывать все это дело можно так: Пример вывода пары кейсов (генерируется автоматически при указании параметра --hypothesis-verbosity=debug): Итоговый вид класса: Ссылки:https://hypothesis.readthedocs.io/en/latest/quickstart.htmlhttps://hypothesis.works/articles/rule-based-stateful-testing/https://hypothesis.works/articles/how-not-to-die-hard-with-hypothesis/https://hypothesis.readthedocs.io/en/latest/stateful.html