Убедитесь, что проверка Joi была добавлена ​​​​в маршрут hapi

Я повторно использую схему Joi в нескольких местах своего кода и хотел бы найти простой способ проверить, назначена ли моим конечным точкам схема проверки. Это было бы полезно, так как я мог проверить, что схема ведет себя так, как я ожидаю, без необходимости повторять одну и ту же серию тестов везде, где используется схема.

Если у меня есть маршрут сервера hapi:

server.route({
  method: POST,
  path: 'myUrl',
  config: {
    validate: {
      payload: validation.myJoiValidation,
    }
  }
})

как мне проверить, что объект validation.myJoiValidation был назначен элементу config.validate.payload?

Я копался в объекте запроса hapi и обнаружил, что то, что я ищу, находится в объекте request.route.settings.validate.payload._inner.children, но я действительно не хочу полагаться на него для того, что я пытаюсь сделать.


node.js validation testing joi hapijs
person garbles    schedule 16.01.2018    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Если у вас есть сервер, работающий в контексте вашего теста, вы можете получить схему проверки, используемую с помощью:

const schema = server.match('post', 'myUrl').settings.validate.payload;

Схемы нельзя сравнивать напрямую (как с Hoek.deepEqual), но их можно сравнивать с помощью joi.describe, поэтому:

expect(joi.describe(schema)).to.equal(joi.describe(validation.myValidation));

Или, если вы используете mocha/chai, я думаю, что это будет:

expect(joi.describe(schema)).to.deep.equal(joi.describe(validation.myValidation));
person tpburch    schedule 06.04.2019

arrow_upward
0
arrow_downward

В своих модульных тестах сделайте запрос с запросом или аналогичным пакетом с полезной нагрузкой, которая не проходит проверка. Убедитесь, что код ответа — 400.

пример теста из мой проект. Он проверяет проверку соединения с регулярным выражением на этом маршруте. Здесь используется небольшая оболочка обещания вокруг запроса, которая называется yarp.

person Gangstead    schedule 17.01.2018
comment
Я уже делаю что-то подобное, но ищу альтернативу. Когда одна и та же проверка используется на нескольких конечных точках, модульные тесты для проверки повторяются. Я хотел бы объединить эти тесты и иметь только один набор тестов для схемы проверки, а затем просто проверить, что каждой конечной точке назначена эта схема проверки. - person garbles; 17.01.2018
comment
Если это схема, которой вы не доверяете, то у вас есть комплексные модульные тесты для схемы (вне любого маршрута), а затем у вас есть только один простой на маршруте, чтобы убедиться, что на нем есть схема. В нашей команде мы исходили из того, что наши юнит-тесты не должны дублировать хапи и дзёи. Если только мы не пытались сделать что-то необычное на конкретном маршруте, мы не проверяли все схемы на каждом маршруте. - person Gangstead; 17.01.2018
comment
Что вы подразумеваете под проверкой наличия схемы на маршруте? Вы имеете в виду любую схему, но не конкретную схему? Причина, по которой я хочу проверить точную применяемую схему, заключается в том, что это приложение предъявляет строгие требования к тому, как должны выглядеть входящие данные. Поэтому я хотел бы убедиться, что схема содержит желаемую проверку Joi, как вы предлагаете, а также убедиться, что точная схема была назначена там, где ожидалось. - person garbles; 17.01.2018
comment
Как я уже сказал, я не повторяю модульные тесты. Если я помещу туда схему, я напишу один модульный тест, чтобы убедиться, что он не принимает искаженную полезную нагрузку. Если это схема, которую я часто использую, я сохраню схему в отдельном файле и напишу кучу тестов для этого модуля, чтобы полностью охватить ее. Там нет идентификатора схемы или чего-либо, что вы можете проверить, находится на маршруте. Если вам абсолютно необходимо проверить точную схему на каждом маршруте, просто напишите функцию, которая берет маршрут и выполняет на нем несколько модульных тестов. - person Gangstead; 19.01.2018