Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
ivanych opened this issue Aug 18, 2017 · 7 comments
Open
Assignees

Comments

@ivanych
Copy link

ivanych commented Aug 18, 2017

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

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

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

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

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

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

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

code: print capture_json()->[0]
# или
validator: [ ( capture_json()->[0] eq 'Пушкин' ), 'Да, автор - Пушкин') ];
@melezhik melezhik self-assigned this Aug 18, 2017
@ivanych
Copy link
Author

ivanych commented Aug 18, 2017

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

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

json: выражение
# или
xml: выражение
# или
yaml: выражение

@melezhik
Copy link
Owner

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

@ivanych
Copy link
Author

ivanych commented Aug 18, 2017

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

@melezhik
Copy link
Owner

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

@melezhik
Copy link
Owner

melezhik commented Aug 18, 2017

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

@ivanych
Copy link
Author

ivanych commented Aug 18, 2017

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

@melezhik
Copy link
Owner

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

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants