Насколько важна проверка на плохие параметры при модульном тестировании?

Question

Допустим, у меня есть метод, который принимает некоторые аргументы и сохраняет их как переменные экземпляра. Если один из них имеет значение null, какой-то код позже потерпит крах. Измените ли вы метод для исключения, если заданы нулевые аргументы, и добавьте модульные тесты, чтобы проверить это или нет? Если я это сделаю, то это будет немного сложнее, так как в javascript есть много неправильных значений (null, undefined, NaN и т. Д.), И поскольку он имеет динамическую типизацию, я даже не могу проверить, был ли передан правильный тип объекта.

Answer 1

Я думаю, что у вас действительно есть 2 разных вопроса.

Первый - это лучший метод проверки правильности ввода параметров, а второй - тест вашего дескриптора модульного теста в этих ситуациях.

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

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

Answer 2

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

Answer 3

JavaScript имеет instanceof и typeof , которые могут помочь вам проверить, какие объекты передаются вашим функциям:

'undefined' == typeof noVariable; // true
var noVariable = null;
'undefined' == typeof noVariable; // false
typeof noVariable; // 'object'
noVariable === null; // true

var myArray = [];
typeof myArray; // 'object'
myArray instanceof Object; // true
myArray instanceof Array; // true

var myObject = {};
typeof myObject; // 'object'
myObject instanceof Object; // true
myObject instanceof Array; // false

Вы можете использовать их для установки некоторых «плохих» значений по умолчанию для переменных вашего экземпляра:

function myFunction(foo,bar) {
    foo = foo instanceof Array ? foo : []; // If 'foo' is not an array, make it an empty one
    bar = bar instanceof Number ? bar : 0;

    // This loop should always exit without error, although it may never do a single iteration
    for (var i=0; i<foo.length; i++) {
        console.log(foo[i]);
    }

    // Should never fail
    bar++;
}

Оператор или также очень полезен:

function myFunction(blat) {
    var blat = blat||null; // If 'blat' is 0, '', undefined, NaN, or null, force it to be null

    // You can be sure that 'blat' will be at least *some* kind of object inside this block
    if (null!==blat) {
    }
}

Answer 4

Для создания надежного и безопасного кода проверка крайних вариантов является безусловно важной задачей. Положительное и отрицательное тестирование всегда хорошо для качества. Отсутствие отрицательных тестов может укусить вас в долгосрочной перспективе.

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

Answer 5

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