Должен ли я выполнить юнит-тест с данными, которые не должны быть переданы в функцию (неверный ввод)?

Question

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

Вот один из простых примеров, иллюстрирующих то, что я спрашиваю:

функция ROBOT, имеющая один параметр INT. В этой функции я знаю, что допустимый диапазон будет только 0-100. Если используется -1, 101, функция будет прервана.

function ROBOT (int num){
...
...
...
return result;
}

Итак, я решил несколько автоматических тестов для этой функции ...

1. function ROBOT with input argument 0
2. function ROBOT with input argument 1
3. function ROBOT with input argument 10
4. function ROBOT with input argument 100

Но я должен написать тестовые случаи с входным аргументом -1 или 101 для этой функции ROBOT, ЕСЛИ я бы защитил это в моей другой функции, которая вызывает функцию ROBOT ???

5. function ROBOT with input argument -1
6. function ROBOT with input argument 101

Я не знаю, если это необходимо, потому что я думаю, что это избыточность для тестирования -1 и 101. И если действительно необходимо охватить все случаи, я должен написать больше кода для защиты -1 и 101.

Так что в обычной практике TDD вы будете писать контрольные примеры также на -1 и 101 ???

Answer 1

Да, вы должны проверить эти неверные данные.НО, если ваш язык имеет модификаторы доступности, а ROBOT() является приватным, вам не следует его тестировать;вам следует проверять только общедоступные функции / методы.

---

Метод функционального тестирования называется Анализ граничных значений .

Если ваш диапазон равен 0-100, ваша границазначения 0 и 100. Вы должны проверить, как минимум :

• ниже значения границы
• значение границы
• выше границызначение

В этом случае:

-1,0,1,
99,100,101

Вы принимаете все от -1 до-infinity ведет себя одинаково, все между 1-99 ведет себя одинаково и все выше 101 ведет себя одинаково.Это называется Эквивалентное разбиение .Диапазоны вне и между граничными значениями называются разделами, и вы предполагаете, что они будут вести себя эквивалентно.

Вы должны всегда использовать -1 в качестве контрольного примера, чтобы убедиться, что с отрицательными числами и текстом ничего смешного не происходитстрока, если параметр не является строго типизированным.

Answer 2

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

Edit:

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

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

Answer 3

Короче говоря, если он может сломаться, то вы должны это проверить.Также проверьте данные как можно раньше.

Ответ зависит от того, управляете ли вы входами, передаваемыми роботу.Если Robot является внутренним классом (C #);значения поступают только из RobotClientX, который является публичным типом.Затем я поместил бы контрольные проверки в RobotClientX, написал тесты для него.Я бы не стал писать тесты для робота, потому что недопустимые значения не могут материализоваться между ними.например, если я помещаю свои проверки в GUI таким образом, чтобы все недопустимые значения отфильтровывались в источнике, то я не проверяю недопустимые значения во всех классах ниже GUI (если только я не выставил публичный API, который обходит GUI).

С другой стороны, если робот общедоступен, т. Е. Любой может вызывать робот с любым значением, которое ему нравится, тогда мне нужны тесты, которые документируют его поведение с учетом определенных видов ввода ... недопустимый, будучи одним из них,например, если вы передадите значение вне диапазона, оно выдаст исключение ArgumentException.

Answer 4

Вы сказали, что ваш метод вызовет исключение, если аргумент недействителен.

Итак, да, вы должны, потому что вы должны проверить, что исключение возникает.

Answer 5

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

Answer 6

Стиль программирования и реализации по контракту привлекает внимание к тому факту, что одна функция (метод) должна отвечать только за некоторые вещи, а не за все. Другие функции, которые он вызывает (делегирует) и которые его вызывают, также имеют обязанности. Этот раздел обязанностей лежит в основе разделения задачи программирования на более мелкие задачи, которые можно выполнять отдельно. контракт часть программирования по контракту заключается в том, что спецификация функции говорит, что функция должна делать тогда и только тогда, когда вызывающая функция выполняет обязанности, возложенные на нее Спецификация. Требование, что входное целое число находится в диапазоне [0,100], является таким требованием.

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

Комбинируя эти две идеи, как мы можем написать тест для функции, которой дан некоторый конкретный неверный ввод? Мы должны проверить, что функция ведет себя согласно спецификации *. Но в спецификации не сказано, что должна делать функция в этом случае. Поэтому мы не можем писать какие-либо проверки состояния программы после неверного вызова функции; поведение не определено . Поэтому мы не можем написать такой тест вообще.

Answer 7

Мой ответ таков: нет, вам не нужны исключения, вам не нужно, чтобы ROBOT() проверял вход за пределами диапазона.Клиенты должны вести себя так хорошо, чтобы они не передавали значения мусора.

Возможно, вы захотите задокументировать это - просто скажите, что клиенты должны быть осторожны с передаваемыми значениями.

Кроме того, где вы собираетесь получить недопустимые значения?Ну, пользовательский ввод или путем преобразования строк в числа.Но в этих случаях именно процедуры преобразования должны выполнять проверки и давать обратную связь о том, являются ли значения действительными или нет.Значения должны быть гарантированно действительными задолго до того, как они приблизятся к ROBOT()!