Как обрабатывать разные параметры пути для разных сред с помощью pactjs

Я начал внедрять PACT для тестирования CDC. Как я могу справиться со сценарием, когда мы передаем разные параметры в пути для разных сред?

Например, мой тест вызывает функцию, которая запрашивает некоторые данные из службы, обращаясь к конечной точке и передавая некоторые параметры. Очень стандартно.

E.G: api/nodeId/${nodeId}/userId/${userId}

Для разных сред (QA, UAT и т. д.) необходимо передать уникальные данные, характерные для этой среды, чтобы получить действительный ответ 200. Поэтому в моем примере carId и userId должны быть разными для каждой среды. Когда я изначально настраивал свой тест, я использовал нашу среду QA и получил следующий контракт.

{
  "consumer": {
    "name": "myConsumer"
  },
  "provider": {
    "name": "myProvider"
  },
  "interactions": [
    {
      "description": "a request to view nodes",
      "request": {
        "method": "GET",
        "path": "/api/nodeId/RRTT6-3AFA-4B5B-BF76-5B6AC7/userId/123456789",
        "headers": {
          "Content-Type": "application/x-www-form-urlencoded",
        }
      },
      "response": {
        "status": 200,
        "headers": {
          "Content-Type": "application/json"
        },
        "body": {
          "startTime": 1549652248000,
          "endTime": 1549911448000,
          "startPrice": 83576,
          "reservePrice": 83876,
          "price": 84576,
          "status": null,
          "groupList": [
            "78945"
          ],
          "bids": 0,
        }
      }
    }
  ],
  "metadata": {
    "pactSpecification": {
      "version": "2.0.0"
    }
  }
}

Как вы можете видеть, путь в контракте имеет жестко заданные nodeId и userId. Если бы я попытался проверить в другой среде, эти тесты потерпели бы неудачу. Итак, как я могу повторно использовать один и тот же контракт для разных сред? В настоящее время для разных сред я создаю отдельный контракт для каждой, но, похоже, должен быть другой способ.


javascript pact
person user1523236    schedule 19.07.2018    source источник

Ответы (3)


arrow_upward
1
arrow_downward

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

например с сопоставлениями путей:

const { Pact, Matchers } = require('@pact-foundation/pact');
const { term } = Matchers;

provider.addInteraction({
  state: 'has node ID 1234 and user with ID 5678',
  uponReceiving: 'a request to view nodes',
  withRequest: {
    method: 'GET',
    api/nodeId/${nodeId}/userId/${userId}
    path: term({ generate: '/api/nodeId/RRTT6-3AFA-4B5B-BF76-5B6AC7/userId/123456789', matcher: '/api/nodeId/[A-Z0-9\-]+/userId/[0-9]+' })
  },
  willRespondWith: {
    status: 200,
    headers: {
      'Content-Type': 'application/x-www-form-urlencoded'
    },
    body: { ... }
  }
})
person Matthew Fellows    schedule 21.07.2018
comment
Спасибо, Мэтью. Это именно то, что я искал. - person user1523236; 23.07.2018

arrow_upward
0
arrow_downward

Обычно не рекомендуется полагаться на переменные внешней среды для запуска тестов, главным образом потому, что одним из преимуществ использования контрактов, управляемых клиентом, является то, что ваши производители могут быть протестированы изолированно, даже изолированно от среды. Это означает, что ваши тесты должны настраивать то, от чего они зависят, или быть гибкими и не зависеть от конкретной конфигурации среды. Это то, что вы должны делать для любого автоматизированного теста, не только CDC.

В вашем сценарии вы могли бы, например, создать пользователя, указанного в контракте, до начала вашего теста или смоделировать ваш пользовательский адаптер, чтобы вернуть действительного пользователя независимо от переданного идентификатора пользователя. Ответ здесь будет зависеть от того, как ваш потребитель использует nodeId и userId.

person Fabricio Lemos    schedule 20.07.2018
comment
Привет, Фабрицио. - Спасибо за ответ! - person user1523236; 23.07.2018

arrow_upward
0
arrow_downward

Проверка поставщика обычно выполняется для локально работающего поставщика на вашем локальном компьютере или в узле построения непрерывной интеграции. Он не предназначен для запуска в развернутой среде, и это несколько противоречит цели его использования таким образом. Преимущество контрактного тестирования заключается в том, что вы должны знать перед развертыванием, будут ли сервисы работать вместе. Присоединяйтесь к нам на slack.pact.io и поговорите с нами, если вас это смущает.

person Beth Skurrie    schedule 22.07.2018
comment
Привет, Бет. Нет, это имеет смысл. Первоначально я думал, что было бы проще настроить и запустить его, если бы мы использовали существующую тестовую среду с данными, но теперь я вижу, что это создает собственную сложность. Спасибо за ваш отзыв! - person user1523236; 24.07.2018