-
Notifications
You must be signed in to change notification settings - Fork 12
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
Comments
Перечитал и подумал, что тут прямо-таки напрашивается возможность делать плагины Swat::Format:* для разных форматов. Плагин должен предоставлять функцию валидации $body на соответствие формату и функцию поиска в $body по выражению. А запускается плагин при встрече в чек-листе инструкции c именем формата:
|
интересно ... надо подумать ... все зависит от того, насколько легко swat сделать расширяемый ... код был написан давно ... подумаю и позже дам ответ ... |
Еще тут подумал - вот, скажем, проверка простого текста - это ведь, по сути, такой плагин Swat::Format::Txt (но, конечно, не оформленный сейчас явно в виде плагина). Встречается в чек-листе текстовое выражение, запускается текстовый плагин, в котором вызывается функция поиска по выражению. А функция просто циклом проходит по $body. |
Тут есть такая проблема. Swat использует Outthentic::DSL для парсинга правил из проверочных файлов, что бы как вы хотите добавились новые синтаксические конструкции вида |
Но сделать возможным определять set_response_processor ввиде внешних плагинов - это вполне реализуемо |
Ненене, делать это через set_response_processor - этого как-раз не хочется. Потому что set_response_processor меняет ответ, а хочется как-раз не менять его. Изменение ответа вынуждает описывать логику в двух местах - в самом set_response_processor и в чек-листе. А хочется только в чек-листе. |
Я тут подумал. Все-таки хочется оставить Outthentic::DSL достаточном простым, т.е. что бы он умел работать только с обычным текстом, построчно ( Я пока здесь никаких неудобств не вижу, кроме того, что придется для каждого роута, который возвращает данные в JSON определять свой response process, но с другой стороны тебе дает это гибкость - так как на этом этапе ты можешь отфильтровать все "лишние" данные и подать на вход для тестирования через Outthentic::DSL только те, которые тебе нужно, сузить так сказать контекст ... И потом тебе так или иначе все равно под каждый запрос приходится писать свои проверочные правила ... Просто здесь у тебя проверка как бы разбивается на два этапа:
|
Это такой фич-реквест. Было бы очень круто.
swat предназначен для веба. А в вебе нынче обычным делом является json. Практически все API выдают json.
Было бы очень удобно, если бы swat мог работать с json-ом без написания вручную кучи вспомогательного кода в set_response_processor.
Как мне это видится:
swat, встретив инструкцию jsonpath, понимает, что проверяемый текст - это json. Тогда swat запускает функцию, которая декодирует $body как json (JSON::XS). Если декодирование не удалось, то проверка сразу провалена. Если же удалось, то поехали дальше (и можно где-то внутри взвести флаг, означающий, что валидность этого json-a проверена и больше валидировать не надо, если вдруг в чек-листе будут еще инструкции jsonpath).
Выражение jsonpath применяется к $body. Если вернулось хоть что-то, то проверка пройдена (а вернувшееся нужно записать, как записываются захваты в регулярке, чтобы потом можно было получить это через функцию - например, через capture_json()).
Дальше в чек-листе можно написать, опять же, по аналогии с регуляркой, что-то такое:
The text was updated successfully, but these errors were encountered: