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

Как проверить функцию, которая использует несколько хорошо проверенных, но сложных функций?

0 голосов
/ 04 марта 2019

Я - любитель в тестировании и пытаюсь научиться писать лучшие тесты.Прямо сейчас у меня есть следующая ситуация с псевдокодом: 

function doSomething() {
    context = prepare();
    result = doActualWork(context);
    notify(result);
}

Вы можете себе представить, что prepare(), doActgualWork() и notify() являются некоторыми сложными функциями со многими меньшими функциями внутри, но они охватываются тестамичто может включать в себя модульные тесты, а также интеграцию, а некоторые - макеты HTTP / IO.

Теперь, когда дело доходит до этой doSomething() функции, я немного запутался в том, что мне следует делать именно для ее тестирования.Я думаю, что стоит проверить соответствие интерфейсов: context, возвращаемое prepare(), может быть передано в doActualWork(), но затем проверяется фактическая реализация.

Другой способ также может бытьтестирование с вводом дает правильные результаты, так как базовые функции довольно сложны, мне нужно будет смоделировать все HTTP / IO, это звучит немного странно, потому что я обычно заканчиваю большими тестовыми примерами со многими подготовительными работами, ивызов функции и утверждение - это только последние несколько строк.

Просто нехорошо так поступать.

Любая помощь и руководство приветствуются.Спасибо.

1 Ответ

0 голосов
/ 05 марта 2019

Вы уже правильно рассматриваете эту проблему тестирования.

Этот фрагмент кода не подходит для модульного тестирования: с помощью модульного тестирования вы пытаетесь найти ошибки в небольших, изолированных частях программного обеспечения.,Но какие ошибки могут быть в этом примере кода, которые не связаны с другими компонентами?Ошибки здесь касаются таких вопросов, как «я вызываю правильные функции с правильными значениями для аргументов в правильном порядке аргументов, является ли другой компонент в правильном состоянии (например, инициализирован), и это возвращаемые значения и побочные эффекты, как я ожидаюим быть?Все эти вопросы связаны с интеграционным тестированием.

Плюс, есть еще один аспект интеграционного тестирования, который фокусируется не на взаимодействиях, а на компоненте в целом - иногда его называют тестированием компонентов, тестированием подсистем и т. Д.обнаружение ошибок, таких как: «правильные версии интегрированных компонентов, все функции, которые ожидаются от компонента на месте» и т. д.

Оба эти типа тестирования будут иметь смысл для данного примера кода, ии то, и другое будет выполнено с зависимыми компонентами, которые фактически находятся в нужных версиях.Используете ли вы по-прежнему какие-то макеты для косвенных зависимостей (например, макеты для запросов http, происходящих внутри зависимых компонентов) - это отдельная история.

Напротив, создание двойников / насмешек для вызовов на prepare(), doActualWork() и notify() только для того, чтобы иметь возможность создавать юнит-тесты для doSomething(), вряд ли поможет вам.Поскольку вы реализуете эти макеты, они будут отражать только ваше потенциальное неправильное понимание этих функций.

...