При каких условиях должны падать unit-тесты?

Unit-тесты должны падать, когда они обнаруживают проблему или несоответствие ожидаемому поведению. Это их основная функция — сигнализировать о необходимости внимания к коду.

Основные условия, при которых корректно написанный unit-тест должен падать:

1. Обнаружение бага (регрессии): Если новый код или изменения в существующем коде приводят к нарушению ранее работавшей функциональности, тесты должны это выявить. Это ключевая роль тестов в предотвращении регрессий.
2. Изменение требований или логики: Когда функциональность, которую тестирует юнит-тест, намеренно изменяется, и тест больше не соответствует новому поведению. В этом случае тест падает, сигнализируя о необходимости его обновления в соответствии с новыми требованиями.
3. Разработка через тестирование (TDD): При использовании TDD, тест пишется до реализации функциональности. Он должен падать, пока функциональность не будет реализована корректно.
4. Нарушение контракта/интерфейса: Если изменяются входные параметры, возвращаемые значения или типы данных тестируемого модуля, и эти изменения несовместимы с ожиданиями теста.
5. Устаревший или удаленный код: Если тестируемый модуль был удален или его API кардинально изменилось, тест, зависящий от него, должен падать, указывая на необходимость его удаления или переписывания.

Пример хрупкого (fragile) теста, который может падать по нерелевантным причинам:

import datetime

def get_current_hour():
    """Возвращает текущий час в формате HH."""
    return datetime.datetime.now().strftime("%H")

# Этот тест будет падать, если текущий час не 10:00
def test_get_current_hour_is_10am():
    assert get_current_hour() == "10"

Такой тест падает не из-за бага в get_current_hour, а из-за зависимости от внешнего фактора (текущего времени). Unit-тесты должны быть детерминированными — при одних и тех же входных данных они всегда должны давать один и тот же результат. Падение из-за недетерминированности указывает на проблему в самом тесте или его изоляции.