Есть ли смысл в написании модульного теста, который является подмножеством другого теста?

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

def test_length():
    result = my_function()
    assert len(result) == 2

def test_order()
    a, b = my_function()
    assert a < b

Здесь, если test_lengthне test_orderполучится , то тоже не получится. Лучше написать test_lengthили пропустить?

РЕДАКТИРОВАТЬ: обратите внимание, что в этой ситуации оба теста в основном независимы друг от друга, каждый может быть запущен в отдельности, или они могут быть запущены в обратном порядке, это не имеет значения. Так что ни один из этих бывших вопросов

• Как я должен проверить функциональность функции, которая использует в ней другие функции?
• Нужен ли мне модульный тест, если у меня уже есть интеграционный тест?
• Как структурировать тесты, где один тест является настройкой другого теста?
• Как управлять зависимостью успеха между юнит-тестами

является дубликатом вышеупомянутого.

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

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

Ваши тесты должны быть явными. Это не совсем вывод, что если text_length терпит неудачу, test_order терпит неудачу.

Я не уверен, как обстоят дела в Python, который вы опубликовали, но если len(result)3, то первое не получится, но второе может пройти (и если не в Python, то в таких языках, как JavaScript, конечно).

Как вы сказали, вы хотите проверить, что функция возвращает два числа и что они в порядке. Два теста это так.

Единственное значение test_lengthздесь состоит в том, что, если все проходит, само его присутствие указывает, что «длина» была проверена.

Так что на самом деле нет необходимости иметь оба этих теста. Оставьте только, test_orderно подумайте о переименовании test_length_and_order.

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

Я бы оставил эти тесты отдельно, если бы они так развивались. Да test_order, скорее всего, потерпит неудачу test_length, но вы определенно знаете, почему.

Я также согласен с тем, что, если он test_orderпоявился первым, и вы обнаружили, что тестируемый сбой состоял в том, что результатом, возможно, были не два значения, добавьте эту проверку как assertи переименуйте тест, чтобы иметь test_length_and_orderсмысл.

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

Но обратите внимание, теперь у вас есть батарея тестов на результат my_function(). Если есть несколько контекстов (или, что более вероятно, несколько параметров) для проверки, теперь это может быть подпрограмма для проверки всех результатов my_function().

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

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