Open ivanych opened 7 years ago
Перечитал и подумал, что тут прямо-таки напрашивается возможность делать плагины Swat::Format:* для разных форматов. Плагин должен предоставлять функцию валидации $body на соответствие формату и функцию поиска в $body по выражению.
А запускается плагин при встрече в чек-листе инструкции c именем формата:
json: выражение
# или
xml: выражение
# или
yaml: выражение
интересно ... надо подумать ... все зависит от того, насколько легко swat сделать расширяемый ... код был написан давно ... подумаю и позже дам ответ ...
Еще тут подумал - вот, скажем, проверка простого текста - это ведь, по сути, такой плагин Swat::Format::Txt (но, конечно, не оформленный сейчас явно в виде плагина). Встречается в чек-листе текстовое выражение, запускается текстовый плагин, в котором вызывается функция поиска по выражению. А функция просто циклом проходит по $body.
Тут есть такая проблема. Swat использует Outthentic::DSL для парсинга правил из проверочных файлов, что бы как вы хотите добавились новые синтаксические конструкции вида xml: , json:
и прочее нужно расширять сам Outthentic::DSL, а это уже гораздо сложнее
Но сделать возможным определять set_response_processor ввиде внешних плагинов - это вполне реализуемо
Ненене, делать это через set_response_processor - этого как-раз не хочется. Потому что set_response_processor меняет ответ, а хочется как-раз не менять его. Изменение ответа вынуждает описывать логику в двух местах - в самом set_response_processor и в чек-листе. А хочется только в чек-листе.
Я тут подумал. Все-таки хочется оставить Outthentic::DSL достаточном простым, т.е. что бы он умел работать только с обычным текстом, построчно (строка или regexp:
) или поблочно (between:, block:
)... Если хочется обрабатывать структурированный текст, то я бы все же предложил делать это через response_processor
... , что бы он переводил выходные данные в формат, "совместимый" с проверочными правилами Outthentic::DSL.
Я пока здесь никаких неудобств не вижу, кроме того, что придется для каждого роута, который возвращает данные в JSON определять свой response process, но с другой стороны тебе дает это гибкость - так как на этом этапе ты можешь отфильтровать все "лишние" данные и подать на вход для тестирования через Outthentic::DSL только те, которые тебе нужно, сузить так сказать контекст ... И потом тебе так или иначе все равно под каждый запрос приходится писать свои проверочные правила ... Просто здесь у тебя проверка как бы разбивается на два этапа:
1) repsponse_processor
обрабатывает входные данные и делает базовую, первичную проверку, типа что у тебя валидный JSON и так далее
2) Проверочные правила делают более глубокую, адресную проверку - что у тебя в ответе пришли именно те сущности, что ты ожидаешь
Это такой фич-реквест. Было бы очень круто.
swat предназначен для веба. А в вебе нынче обычным делом является json. Практически все API выдают json.
Было бы очень удобно, если бы swat мог работать с json-ом без написания вручную кучи вспомогательного кода в set_response_processor.
Как мне это видится:
1) В чек-листе, по аналогии с регуляркой, пишем выражение на jsonpath (JSON::Path):
2) swat, встретив инструкцию jsonpath, понимает, что проверяемый текст - это json. Тогда swat запускает функцию, которая декодирует $body как json (JSON::XS). Если декодирование не удалось, то проверка сразу провалена. Если же удалось, то поехали дальше (и можно где-то внутри взвести флаг, означающий, что валидность этого json-a проверена и больше валидировать не надо, если вдруг в чек-листе будут еще инструкции jsonpath).
3) Выражение jsonpath применяется к $body. Если вернулось хоть что-то, то проверка пройдена (а вернувшееся нужно записать, как записываются захваты в регулярке, чтобы потом можно было получить это через функцию - например, через capture_json()).
4) Дальше в чек-листе можно написать, опять же, по аналогии с регуляркой, что-то такое: