Как писать тесты для строк?

120

31 марта 2021, 11:50

У меня есть функция которая берет строку и проверяет является ли она CSS функцией hsla. CSS понимает разное написание этой функции — с тремя и четырьмя аргументами, без пробелов и с сотнями пробелов, а так же не понимает если нет знака процента у одного из трех аргументов.

Сейчас в тестах я учитываю все эти особенности, из-за чего код теста сильно раздувается:

test('Use hsl with wrong percentage placement', ()=>{
    expect(isHsl('hsl(360%, 100%, 100%)')).toBe(false);
    expect(isHsl('hsl(360, 100, 100%)')).toBe(false);
    expect(isHsl('hsl(360, 100%, 100)')).toBe(false);
    expect(isHsl('hsl(360, 100, 100)')).toBe(false);
    expect(isHsl('hsl(360, 100 %, 100)')).toBe(false);
    expect(isHsl('hsl(360, 100, 100 %)')).toBe(false);
    expect(isHsl('hsl(360, %100, 100)')).toBe(false);
    expect(isHsl('hsl(360, 100, %100)')).toBe(false);
});

Вот например тест на число пробелов который предлагает сомнительную пользу — все равно я не смогу проверить все возможные комбинации пробелов:

test('Check hsl with irregular spacing and get true', ()=>{
    expect(isHsl('hsl(12,1%,13%)')).toBe(true);
    expect(isHsl('hsl( 12 , 1% , 13% )')).toBe(true);
    expect(isHsl('hsl(  12  ,  1%  ,  13%  )')).toBe(true);
});

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

Как правильно тестировать такие функции?

Answer 1

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

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

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

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

Формальные методы. В случае, если разрабатываемая Вами функция будет использоваться в космическом аппарате, медицинском оборудовании или на АЭС можно обратиться к формальным методам тестирования. В таком подходе разработка программ ведётся через формальное описание того что должна система делать, вместо описания того, как она это будет делать. После создания такого описания мы можем выполнить полную валидацию полученного решения.