Функция модульного тестирования, вызывающая другую функцию

unit-testing functional-programming elixir

168 просмотра

2 ответа

Скажем, у меня есть две следующие функции:

add_five (number) -> number + 2

add_six (number) -> add_five(number) + 1

Как видите, add_fiveесть ошибка.

Если я сейчас протестирую, add_sixон потерпит неудачу, потому что результат неверен, но код верен .

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

Итак, мой вопрос: если модульные тесты не пройдут из-за неправильного поведения (неправильные результаты) или из-за неправильного кода (ошибки)

Автор: Jan-Paul Kleemans Источник Размещён: 08.11.2019 11:11

Ответы (2)


3 плюса

Решение

должны ли модульные тесты проваливаться из-за неправильного поведения (неправильные результаты) или из-за неправильного кода (ошибки)?

Модульные тесты обычно терпят неудачу из-за неправильных результатов. Это то, что вы пишете в утверждениях: вы вызываете метод и определяете ожидаемый результат.

Модульные тесты не могут идентифицировать неправильный код. Если выполняется операция, return number+5и у вашего ЦП или ОЗУ возникла аппаратная проблема, и она возвращает что-то другое, то проверка также не пройдёт, даже если код верный.

Также учтите:

public int add_five(int number)
{
    Thread.Sleep(5000);
    return number+5;
}

Как модульный тест узнает, предназначен ли сон или нет?

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

Автор: Thomas Weller Размещён: 20.08.2016 11:48

0 плюса

Предположительно у вас есть тест для add_five/1и тест для add_six/1. В этом случае проверка add_six/1не будет выполнена одновременно с проверкой add_five/1.

Предположим, вы решили проверить в add_six/1первую очередь. Вы видите, что это зависит от того add_five/1, что тоже терпит неудачу. Вы можете сразу предположить, что ошибка в ней add_five/1накапливается.

Зависимости вашего модуля образуют ориентированный (возможно, ациклический) граф. Если зависимость вашей функции или модуля нарушена, это должно быть тем, на что вы нацелены в первую очередь для отладки.

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

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

Автор: Cody Poll Размещён: 21.08.2016 06:44
Вопросы из категории :
32x32