Политика обратной совместимости

pytest активно развивается и является проектом, который создавался десятилетиями, мы продолжаем узнавать о новых и лучших структурах для выражения различных деталей тестирования.

Пока мы внедряем эти изменения, мы стараемся обеспечить легкий переход и не хотим навязывать ненужную возню нашим пользователям и сообществу/авторам плагинов.

На данный момент pytest учитывает несколько типов переходов на обратную совместимость:

  1. тривиальные: API, которые тривиально переводятся на новый механизм и не вызывают проблемных изменений.

    Мы стараемся поддерживать их бесконечно долго, одновременно поощряя пользователей к переходу на более новые/лучшие механизмы с помощью документации.

  2. переходный: старый и новый API не конфликтуют, и мы можем помочь пользователям перейти на новый API, используя предупреждения, при этом поддерживая оба API в течение длительного времени.

    Мы начнем удаление устаревшей функциональности только в основных релизах (например, если мы обесценили что-то в 3.0, мы начнем удалять это в 4.0), и сохраним ее по крайней мере в двух второстепенных релизах (например, если мы обесценили что-то в 3.9, а 4.0 - следующий релиз, мы начнем удалять это в 5.0, а не в 4.0).

    Устаревшая функция, которую планируется удалить в основной версии X, будет использовать класс предупреждения PytestRemovedInXWarning (подкласс PytestDeprecationwarning).

    Когда срок устаревания истечет (например, выйдет 4.0), мы не будем удалять устаревшую функциональность немедленно, а воспользуемся стандартными фильтрами предупреждений, чтобы превратить PytestRemovedInXWarning (например, PytestRemovedIn4Warning) в ошибки по умолчанию. Такой подход делает очевидным, что удаление неизбежно, и при этом дает вам время превратить устаревшую функцию в предупреждение вместо ошибки, чтобы с ней можно было разобраться в свое время. В следующем минорном выпуске (например, 4.1) функция будет фактически удалена.

  3. истинная поломка: должна рассматриваться только в тех случаях, когда обычный переход неоправданно неустойчив и может отсрочить важные разработки/функции на годы. Кроме того, они должны быть ограничены API, где число реальных пользователей очень мало (например, затрагивая только некоторые плагины), и могут быть заранее согласованы с сообществом.

    Примеры таких предстоящих изменений:

    • удаление pytest_runtest_protocol/nextitem - issue #895

    • перестановка дерева узлов для включения FunctionDefinition

    • перестановка SetupState issue #895

    Настоящие поломки должны быть объявлены первыми в выпуске, содержащем:

    • Подробное описание изменения

    • Обоснование

    • Ожидаемое влияние на пользователей и авторов плагинов (пример в issue #895)

    Если по вопросу нет твердых -1, за ним должен последовать первоначальный Pull Request для проверки концепции.

    Этот СПЭ служит как координационным пунктом для оценки воздействия, так и потенциальным вдохновением для того, чтобы все-таки придумать переходное решение.

    По прошествии разумного количества времени PR может быть объединен в основу нового основного релиза.

    Чтобы PR прошел путь от POC до принятия, он должен содержать: * Установку ошибок/предупреждений о депривации, которые помогут пользователям исправить и перенести свой код. Если есть возможность ввести период депривации в рамках текущей серии, до истинной поломки, он должен быть представлен в отдельном PR и быть частью текущего потока релизов. * Подробное описание обоснования и примеры по переносу кода в doc/en/deprecations.rst.

История

Сосредоточьтесь в первую очередь на плавном переходе - стойке (до 6.0)

Поддержание обратной совместимости имеет очень высокий приоритет в проекте pytest. Несмотря на то, что за прошедшие годы функциональность была упразднена, большая ее часть все еще поддерживается. Все изъятия в pytest были сделаны потому, что появились более простые или более эффективные способы выполнения тех же задач, делая старый способ выполнения ненужным.

В релизе pytest 3.0 мы ввели четкую схему коммуникации о том, когда мы действительно удалим старую устаревшую функциональность и вежливо попросим вас использовать вместо нее новую, давая вам достаточно времени, чтобы скорректировать ваши тесты или выразить беспокойство, если есть веские причины для сохранения устаревшей функциональности.

Чтобы сообщить об изменениях, мы выпускаем предупреждения об устаревании, используя собственную иерархию предупреждений (см. Внутренние предупреждения pytest). Эти предупреждения могут быть подавлены стандартными средствами: -W флаг командной строки или filterwarnings параметры ini (см. Как фиксировать предупреждения), но мы рекомендуем использовать их редко и временно, и прислушиваться к предупреждениям, когда это возможно.

Мы начнем удаление устаревшей функциональности только в основных релизах (например, если мы обесценили что-то в 3.0, мы начнем удалять это в 4.0), и сохраним ее по крайней мере в двух второстепенных релизах (например, если мы обесценили что-то в 3.9, а 4.0 - следующий релиз, мы начнем удалять это в 5.0, а не в 4.0).

Когда срок устаревания истечет (например, выйдет 4.0), мы не будем сразу удалять устаревшие функции, а воспользуемся стандартными фильтрами предупреждений, чтобы превратить их в ошибки по умолчанию. Такой подход дает понять, что удаление неизбежно, и при этом дает вам время превратить устаревшую функцию в предупреждение, а не в ошибку, чтобы вы могли разобраться с ней в свое время. В следующем минорном выпуске (например, 4.1) функция будет фактически удалена.

Дорожная карта амортизации

Функции, в настоящее время устаревшие и удаленные в предыдущих выпусках, можно найти в Амортизация и удаление.

Мы отслеживаем будущее обесценивание и удаление функций с помощью вех и меток deprecation и removal на GitHub.

Поддержка версий Python

Выпущенные версии pytest поддерживают все версии Python, которые активно поддерживаются на момент выпуска:

версия pytest

min. Версия Python

7.1+

3.7+

6.2 - 7.0

3.6+

5.0 - 6.1

3.5+

3.3 - 4.6

2.7, 3.4+
Работа с непитоновскими тестами
Амортизация и удаление
Back to Top