Создание утилиты тестирования для парсеров полученных с помощью нового генератора парсеров (аналогичная тестовой утилите применяемой для тестирования компилятора Н1).

Это должен быть ехе-шник с именем, предположим, test.exe.

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

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

Опции командной строки

Пример командной строки:

test.exe bin\Debug\N2Parser.dll /parser:SomeNs.N2Parser /ext:"n" /tests_path:..\Tests\Positive  /debug

Путь к сборке содержащей парсер задается аргументом командной строки перед которым не идет '/' или '-'.
Так же должны поддерживаться следующие опции командной строки:
/parser:"квалифицированное имя класса парсера который надо загрузить"
/ext:"имена расширений тестовых файлов перечисленные через ';'"
/tests_path:"относительный (от текущего каталога) путь к тестовым файлам"
/debug — выдавать assert2(false) в случае провала теста с тем чтобы можно было начать отладку теста.

Активная размета

В файлах с тестами должны присутствовать дополнительные описания которые позволят указать дополнительную информацию необходимую для проверки правильности работы парсера.

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

В начале любого тестового файла могут следовать следующие строки содержащие общие настройки:

// OPTION: настройки парсера (пока ничего)

Внутри кода, в конце строк с кодом могут встречаться конструкции:

// E: ...
// W: ...
// H: ...

Где вместо "..." может встречаться произвольный текст ожидаемого сообщения об ошибке. При этом текст интерпретируется как плоский текст (а не как регекс в тестовой утилите Н1).
Если опции описаны так:

// E:R: ...
// W:R: ...
// H:R: ...

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

Внутри кода (но не в приведенных выше конструкциях) могут встречаться конструкции:

/*{*/SomeCode/*} E: образец сообщения*/()

Опять же вместо "E:" могут использоваться "W:", "H:", а так же "E:R:" и т.п.

Кроме того хорошо бы должен поддерживаться гибридный вариант:

/*{*/SomeCode/*}*/() // E: Expected XXX

При этом в строке может быть только одна пара кавычек /*{*/ и /*}*/, которая идентифицирует реальное местоположение ошибки.