Модульные тесты для парсера

Question

Как написать модульные тесты для следующего сценария?

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

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

Проблема

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

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

Тестирование:

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

1.:
"007" - expect: false
"01-001" - expect: true
"R02-33b" - expect: true
"01-001andsometext" - expect: false
"01-001 andsometext" - expect: true
"02-33X" - expect: false
"" - expect: false

2.:
"We meet in R01-001. Please invite agent 007." -- expect 1 matching rooms
"Excercise groups take place in 02-23b and 02-33c." --- expect 2 matches
... 

3.:
Integration test style. 
Long input with room numbers in the texts and in header/footer 
where I only want to recognize n rooms:
"... 150+ character string ..." - expect exactly 7 matches, 
                                  check if the right ones are matched

Несмотря на то, что первый тест представляет собой совершенно прекрасный модульный тест, который действительно тестирует только очень фиксированную часть моей программы, о сложных случаях также очень легко забыть. Глядя на второй пример, я мог бы сказать себе: «Чувак, мне следовало включить тестовый пример, в котором после номера комнаты следуют точка, знак вопроса и т. Д.».

Однако второй пример не намного лучше. В частности, я все еще могу пропустить множество «граничных случаев», потому что для парсера их очень много (другие знаки пунктуации, Unicode и т. Д.).

Но даже помимо этого, я действительно хочу не только обнаруживать номера комнат определенного формата, но и отбрасывать те, которые находятся в «плохих» разделах. Тестирование синтаксического анализа «настоящий / типичный» кажется ужасной практикой модульных тестов: едва читаемый, ожидаемый результат склонен к изменениям в других частях (установленных «плохих» шаблонах) моей программы и т. Д.

Мой вывод пока

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

Answer 1

Существует несколько источников информации, которые вы можете использовать для создания тестовых случаев:

• Требования к документам. Очевидно, ваш код должен быть в состоянии обработать все случаи, упомянутые здесь

• Код. Прочитайте код и спросите себя: какой тип ввода мне понадобится для выполнения этой строки кода? Инструменты покрытия кода очень помогают здесь. Когда тестовые сценарии выполняют каждую строку кода и каждую возможную комбинацию условий во всех if выражениях, вы должны довольно тщательно разобраться в этом

• Подумайте о том, что ваш код должен не принимать. При разборе чисел, как насчет этих входных данных: 0, 0., .0, 0.0, .

• Сообщения об ошибках. Со временем появятся отчеты об ошибках. Поскольку отчеты об ошибках по сути означают «это то, что вы обычно совершаете ошибки», каждый отчет об ошибках должен стать модульным тестом.

Answer 2

Рассматривали ли вы тестирование на основе данных ?В ситуациях, подобных вашей, невозможно проверить все возможные входные данные (ну, когда это возможно на самом деле?), И может помочь некоторый четко определенный набор входных данных.В большинстве современных сред тестирования (например, JUnit или NUnit ) такое тестирование разрешено (например, указывается регистр ввода в файле / базе данных).

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

Answer 3

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