Неверные данные для модульного тестирования в текстовом парсере

Question

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

В методе используется некоторое регулярное выражение плюс манипуляции со строками, но если я хорошо понял подход Unit Testing Мне не нужно концентрироваться на реализации метода, но я вижу его как черный ящик . Правильно?

Метод

Public Function GetSymbol(ByVal symbol As String) As SymbolInfo

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

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

Можете ли вы дать мне несколько советов? Я новичок в модульном тестировании, только что начал.

Answer 1

Я не верю, что подход «черного ящика» абсолютно верен.

Мое мышление будет выглядеть так:

A). Посмотрите на входы. Подумайте, как человек может посылать плохие вещи. Примеры:

• Нулевая ссылка
• Пустая строка
• Очень длинная строка
• Строка со всеми цифрами
• Строка со странными знаками препинания
• Строка с непечатными или странными наборами символов

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

* * 1 022 В). Но теперь мы открываем коробку. Вы смотрите на код и ищите различные его ветви. Ваши тесты тренируют эти ветви? Есть инструменты покрытия для анализа ваших тестов. Предположим, у вас был особый случай: если взять глупый пример, слово MY-SPECIAL-SYMBOL подвергается какой-то специальной обработке, для этого есть «Если». Ваш тестовый пример должен включать это в качестве входных данных. Часто такие угловые случаи можно найти, только взглянув на код. (Да, спецификация должна сказать вам, но разработчики часто находят интересные дополнения, так что посмотрите на код.

С). Как насчет побочных эффектов? Предположим, что этот метод должен обновлять кэш для каждого найденного символа. Это формальное требование компонента, и все же интерфейс этого не говорит. Снова вы идете в черный ящик. Поэтому здесь вы можете использовать mocks, чтобы убедиться, что компонент в свою очередь передал правильные данные в API кеша.

Answer 2

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

Answer 3

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