Тестовая структура, позволяющая тестам зависеть от других тестов

Question

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

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

В качестве бонуса было бы замечательно, если бы был какой-то способ использовать объект, созданный с помощью одного теста, в качестве приспособления для других тестов.

Предоставляется ли этот набор функций какой-либо из платформ тестирования Python? Или такой подход противоречит основной философии модульного тестирования?

Answer 1

Или такой подход противоречит основной философии модульного тестирования?

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

Answer 2

Хоботок - это тестовая среда Python, которая расширяет встроенный модуль юнит-теста Python и Nose с функциями из TestNG.

Похоже на то, что вы ищете,Обратите внимание, что он работает немного иначе, чем unittest и Nose, но на этой странице объясняется, как он работает довольно хорошо.

Answer 3

Это, кажется, повторяющийся вопрос - например, # 3396055

Скорее всего, это не юнит-тест, потому что они должны быть быстрыми (и независимыми).Так что запускать их все не так уж и сложно.Я вижу, где это может помочь в коротких замыканиях интеграционных / регрессионных прогонов, чтобы сэкономить время.Если это является для вас основной потребностью, я бы пометил тесты установки с помощью [Core] или другого такого атрибута.

Затем я продолжаю писать сценарий сборки, который имеет две задачи

• Taskn: запустить все тесты в dll X, Y, Z, помеченных тегом [Core]
• Taskn + 1, зависит от Taskn: запустить все тесты в dll X, Y, Z, кроме тех, которые отмечены тегом [Core]

(Taskn + 1 не должен запускаться, если Taskn не преуспел.) Это не идеальное решение - например, оно просто выручит, если какой-либо один тест [Core] не пройден.Но я полагаю, что вы должны исправить основные из них, вместо того чтобы приступать к тестам без использования ядра.

Answer 4

Все участники тестирования py.test, Nosetests и unit2 / unittest2 поддерживают понятие «выход после первого сбоя».py.test в более общем смысле позволяет указать «--maxfail = NUM» для прекращения работы и создания отчетов после сбоев NUM.Это может уже помочь вашему делу, тем более что поддержание и обновление зависимостей для тестов может быть не такой интересной задачей.

Answer 5

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