Сообщений в теме: 22

[yurock]

С вопросами на счет bnftool рекомендую обращаться к allex'у. Напишите ему в личку, если он здесь не отзывается).
Что касается примеров, то они должны быть по такому вот пути: bnftool-4.0.0-beta-060323\src\bnftool-4.0.0-beta-060323-src.zip\bnftool-4.0.0-beta-060323\examples\bnf\BNF.bnf.
Если не найдете, я могу выслать.

Я искал инструмент для тестирования функции Проверка Синтаксиса для SQL редактора, т.е. мне были нужны разные SQL запросы. Немного экспериментировал с bnftool. Составил BNF вида

grammar ::= "select count(*), a" 
"from table1"
( "where a > 4" )?
( group_clause )?
;

group_clause ::= "group by 1" ( "having count(*) > 4" )?;

Файл bnf.properties полностью такой же как и в примерах, которые прилагаются к программе, файл лексем пустой.
После запуска генерации по команде
bnftool.exe -J-Dbnf.properties.file=bnf.bnf.properties bnf.bnf test_alt -javahome c:\Java\jdk1_6_0_01
В результате получается набор файлов, в каждом по 1 тест-кейсу.

Меня не устроило то, что не был сгенерирован ни один тест-кейс, который содержал бы WHERE и GROUP BY выражения одновременно.
Как пояснил allex, test_alt создавался для тестирования рекурсивных парсеров (LL), поэтому используемый в нем критерий покрытия нацелен на поиск наиболее распространенных ошибок в таких парсерах - неправильное распознавание альтернатив. Поэтому в тестовом наборе будет тест для всех возможных первых токенов всех альтернатив. Комбинации могут не покрываться.
При этом есть возможность написать свой генератор для необходимого критерий покрытия. Генератор, как и все плагины, получает на вход объектную модель входной грамматики (дерево абстрактного синтаксиса+связи между определением и использованием правил).
Этим я еще не занимался, т.к. успел решить задачу с использованием PICT, нагенерил достаточно много разных достаточно сложных запросов, а сейчас уже на очереди другие задачи), пока нет времени.

Многие тест-кейсы дублируются, это нормально. По словам allex'a, есть гарантия, что для связной грамматики покроются все возможные символы всех возможных альтернатив. При создании теста для одной альтернативы несущественные места (контекст) достраиваются первым попавшимся способом, эти куски получаются повторяющимися. В SynTESK, вроде, проблема с дублями частично решена.

[NeOn]

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

Однако осталось несколько вопросов:
1. Почему если я прописываю вероятные идентификаторы переменных в файле лексем (там всего одна строчка: <ID> "id1" "id2" "id3" "id4" - осталась от стандартного, немного только видоизменилась), то тулза при использовании в основной массе использует только первый идентификатор переменной? Может не стоит переменные в лексемах описывать?
2. Насколько я понял синтаксис (...)? является аналогом [...] в стандартной BNF-нотации (поправьте если ошибаюсь). Тогда в чем разница и суть записей типа (...)* и (...)+? Понял только, что это означает, что фраза в скобках будет повторяться несколько раз, причем в случае с + - как минимум раз, в случае с * - может ни разу. Но в любом случае не повторялось более 2 раз. Логики пока не понял.
3. По какому критерию определяется, что должно быть сгенерировано Н-тестов и ни одним более?

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

[allex]

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

yurock, мы таки выкатили CTESK 2.5. Теперь там нет никакого инсталлятора - достаточно просто архив распаковать. Это так, к слову - он не для синтаксического тестирования предназначен, а для тестирования API на языке С, в том числе, со сложным поведением.

Есть еще инструмент DGL, который позволяет генерировать данные на основе контекстно-свободных грамматик. Случайно или систематически. У меня всё руки не доходят с ним поиграться, но по описанию штука довольно мощная.