pact -python для команды QA

Я пытаюсь настроить проект pact python локально и сталкиваюсь с проблемами. было бы здорово, если бы вы мне помогли по этим вопросам

Кажется, нам нужно использовать localhost: 1234 со стороны потребителя? . Можем ли мы использовать реальный сервис вместо имитирующего сервиса? Если я использую localhost: 1234, пакт был сгенерирован, но если я использую реальный сервис, то возникает ошибка Итак, мой вопрос: нужно ли нам всегда использовать Mock service ((localhost: 1234), когда мы создаем пакты со стороны потребителя

2-я проблема: я из команды QA и думаю, что пакты должны быть написаны командой DEV, а не командой QA. мое предположение верно? Если да, то как эти пакты помогут QA Team?

Consumer.py

    import requests
    def callAPI(self,inputString,Url):
    respone = requests.get(url+inputString).status_code

test_consumer.py:

 pact = Consumer ( 'consumer' ).has_pact_with ( Provider ( 'provider' ) )
      pact.start_service ()
      atexit.register ( pact.stop_service )


      def test_callAPI (self):
      url = 'http://localhost:1234'

      pact.given ( 'sending user name to Url'
                 ).upon_receiving (
        'once i get the respone from service'
      ).with_request (
        'get', '/' ).will_respond_with ( 200)

     with pact:
        result = callAPI (url)
        self.assertEqual ( result['status_code'], 200 )

Заранее спасибо,


person beginner    schedule 23.07.2018    source источник


Ответы (1)


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

Вы также можете указать Pact использовать любой порт, это просто значение по умолчанию.

должны ли разработчики их писать ... как это поможет команде QA?

Краткий ответ - да, они действительно должны быть написаны теми, кто пишет код. Это плохо? Как QA я могу представить, что это облегчит вашу работу, поскольку качество автоматически повышается, и вы можете сосредоточиться на более важных действиях, а не на написании тестов автоматизации.

person Matthew Fellows    schedule 28.07.2018