Как структурировать носовые юнит-тесты, которые строятся друг на друге?

Question

Пример

Допустим, у вас есть гипотетический API, подобный этому:

import foo

account_name = foo.register()
session = foo.login(account_name)
session.do_something()

Ключевым моментом является то, что для do_something() вам необходимо зарегистрироваться и войти в систему.

Вот упрощенный, первый проход, набор модульных тестов, который можно написать:

# test_foo.py
import foo

def test_registration_should_succeed():
    foo.register()

def test_login_should_succeed():
    account_name = foo.register()
    foo.login(account_name)

def test_do_something_should_succeed():
    account_name = foo.register()
    session = foo.login(account_name)
    session.do_something()

Проблема

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

Вопрос

Как вы структурируете свои модульные тесты, чтобы последующие тесты не выполнялись при включенной функциональности ядра?от чего они зависят?

Идеи

Вот возможные решения, о которых я подумал.

1. Обнаружение ошибок в каждом тесте вручную и повышение SkipTest.- Работает, но много ручной, подверженной ошибкам работы.
2. Использование генераторов, чтобы не давать последующие тесты, когда первичные проваливаются.- Не уверен, сработает ли это на самом деле (потому что, как я «узнаю», ранее полученный тест не удался).
3. Группировка тестов в тестовые классы.Например, это все модульные тесты, которые требуют, чтобы вы вошли в систему. - Не уверен, что это действительно решает мою проблему.Разве не было бы столько же неудач?

Answer 1

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

Answer 2

Эта проблема указывает на то, что Фу много делает. Вы должны разделить проблемы. Тогда тестирование станет легким. Если бы у вас были Registrator, LoginHandler и класс DoSomething, а также класс центрального контроллера, который организовывал рабочий процесс, то все можно было бы протестировать отдельно.