Как структурировать юнит-тесты, которые имеют зависимости?

Question

Учитывая следующий простой пример:

class MathObject(object):
    """ A completely superfluous class. """ 
    def add(self, a, b):
        return a + b

    def multiply(self, a, b):
        result = 0
        for _ in range(b):
            result = self.add(result, a)
        return result

Очевидно, multiply() вызывает add() внутри страны. Если add терпит неудачу, multiply() тоже терпит неудачу. В достаточно сложном классе было бы действительно сложно выяснить , почему точно не прошел модульный тест.

Каким образом один модуль тестирует методы / объекты / детали, которые имеют зависимости?

Answer 1

Я обычно просто позволяю им терпеть неудачу - классы должны быть достаточно простыми, чтобы быстро определить плохой тест.
Но в сложных случаях мы использовали простые соглашения о присвоении имен для тестов, чтобы обеспечить соблюдение определенного порядка (def test_00_add, def test_01_multiply).

Опять же, если ваши классы станут большими, ими будет сложнее управлять, поэтому просто не делайте их большими:)

Answer 2

Тот факт, что multiply внутренне использует add, является подробностью реализации multiply. Так что не принимайте это во внимание явно в своих тестах и ​​«просто» пишите тесты для проверки функциональности как add, так и multiply.

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

Так что, по сути, я согласен с Abyx. ; -)

Answer 3

Идеальный тестовый бегун бы с этим разобрался.

Кент Бек разработал интеллектуальный тестовый прогон , который выполнял тест на основе статистики отказов и времени выполнения.

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

Answer 4

Это зависит от того, является ли вспомогательный метод / объект / что-либо внутренним элементом реализации или соавтором.

Если есть только один правильный результат для конечного результата, и он никогда не изменится, то, вероятно, стоит проверить их вместе. Но, если поведение «внутреннего» объекта на самом деле является отдельным поведением, вероятно, лучше придерживаться его за интерфейсом.

Я не уверен, ясен ли этот ответ или нет ....

Answer 5

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

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