melezhik / swat

Simple Web Application Test
48 stars 12 forks source link

Поддержка структурированного текста #28

Open ivanych opened 7 years ago

ivanych commented 7 years ago

Это такой фич-реквест. Было бы очень круто.

swat предназначен для веба. А в вебе нынче обычным делом является json. Практически все API выдают json.

Было бы очень удобно, если бы swat мог работать с json-ом без написания вручную кучи вспомогательного кода в set_response_processor.

Как мне это видится:

1) В чек-листе, по аналогии с регуляркой, пишем выражение на jsonpath (JSON::Path):

jsonpath: store.book.author

2) swat, встретив инструкцию jsonpath, понимает, что проверяемый текст - это json. Тогда swat запускает функцию, которая декодирует $body как json (JSON::XS). Если декодирование не удалось, то проверка сразу провалена. Если же удалось, то поехали дальше (и можно где-то внутри взвести флаг, означающий, что валидность этого json-a проверена и больше валидировать не надо, если вдруг в чек-листе будут еще инструкции jsonpath).

3) Выражение jsonpath применяется к $body. Если вернулось хоть что-то, то проверка пройдена (а вернувшееся нужно записать, как записываются захваты в регулярке, чтобы потом можно было получить это через функцию - например, через capture_json()).

4) Дальше в чек-листе можно написать, опять же, по аналогии с регуляркой, что-то такое:

code: print capture_json()->[0]
# или
validator: [ ( capture_json()->[0] eq 'Пушкин' ), 'Да, автор - Пушкин') ];
ivanych commented 7 years ago

Перечитал и подумал, что тут прямо-таки напрашивается возможность делать плагины Swat::Format:* для разных форматов. Плагин должен предоставлять функцию валидации $body на соответствие формату и функцию поиска в $body по выражению.

А запускается плагин при встрече в чек-листе инструкции c именем формата:

json: выражение
# или
xml: выражение
# или
yaml: выражение
melezhik commented 7 years ago

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

ivanych commented 7 years ago

Еще тут подумал - вот, скажем, проверка простого текста - это ведь, по сути, такой плагин Swat::Format::Txt (но, конечно, не оформленный сейчас явно в виде плагина). Встречается в чек-листе текстовое выражение, запускается текстовый плагин, в котором вызывается функция поиска по выражению. А функция просто циклом проходит по $body.

melezhik commented 7 years ago

Тут есть такая проблема. Swat использует Outthentic::DSL для парсинга правил из проверочных файлов, что бы как вы хотите добавились новые синтаксические конструкции вида xml: , json: и прочее нужно расширять сам Outthentic::DSL, а это уже гораздо сложнее

melezhik commented 7 years ago

Но сделать возможным определять set_response_processor ввиде внешних плагинов - это вполне реализуемо

ivanych commented 7 years ago

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

melezhik commented 7 years ago

Я тут подумал. Все-таки хочется оставить Outthentic::DSL достаточном простым, т.е. что бы он умел работать только с обычным текстом, построчно (строка или regexp:) или поблочно (between:, block: )... Если хочется обрабатывать структурированный текст, то я бы все же предложил делать это через response_processor ... , что бы он переводил выходные данные в формат, "совместимый" с проверочными правилами Outthentic::DSL.

Я пока здесь никаких неудобств не вижу, кроме того, что придется для каждого роута, который возвращает данные в JSON определять свой response process, но с другой стороны тебе дает это гибкость - так как на этом этапе ты можешь отфильтровать все "лишние" данные и подать на вход для тестирования через Outthentic::DSL только те, которые тебе нужно, сузить так сказать контекст ... И потом тебе так или иначе все равно под каждый запрос приходится писать свои проверочные правила ... Просто здесь у тебя проверка как бы разбивается на два этапа:

1) repsponse_processor обрабатывает входные данные и делает базовую, первичную проверку, типа что у тебя валидный JSON и так далее 2) Проверочные правила делают более глубокую, адресную проверку - что у тебя в ответе пришли именно те сущности, что ты ожидаешь