Как проверить только подпись JSON (не значения), возвращенную Micro Service с использованием Spring Cloud Contract - PullRequest
0 голосов
/ 22 декабря 2018

У меня есть отличный сценарий, в котором я пытаюсь проверить атрибуты JSON в методе базового класса тестирования (assertDepartment).

import org.springframework.cloud.contract.spec.Contract

Contract.make {

    request {
        method 'GET'
        url '/dept-service/12345'
    }

    response {
        status 200
        headers {
            header 'Content-Type': 'application/json;charset=UTF-8'
        }
        body ($(consumer('dept.json'), producer(execute('assertDepartment($it)'))))
    }
}

dept.json

[{

    "departmentList": [
         {
            "dept_code": "12345",
            "dept_name": "AAA",
            "desc": "aaa",
         },
         {
            "dept_code": "12345",
            "dept_name": "BBB",
            "desc": "bbb",
         }
     ]
}]

С точки зрения издателя, это все хорошо, но заглушки включают JSON со значениями, как есть, согласно описанному выше dept.json.

С точки зрения потребителя,Я хотел бы проверить только подпись JSON, но не по значениям, так как я подключаюсь к другой базе данных.Здесь сравнение JSON является СТРОГОМ по отношению к значениям.Как я могу отправить общий формат JSON в Consumer и как я могу ограничить только проверку атрибутов (например, dept_code, dept_name, desc), а не значений (AAA, aaa, BBB, bbb)

Пожалуйста, помогите.

1 Ответ

0 голосов
/ 25 декабря 2018

После ознакомления с документацией я понял следующее относительно реализации Spring Cloud Contract.- Запрос / ответ Spring Cloud Contract / Response являются статическими, а не динамическими. Мы должны иметь конкретные статические данные запроса / ответа для каждого случая / сценария. Производитель не может переключить его в реальном времени и не может динамически изменять входные данные и ожидать, что Потребитель получитодин и тот же вывод

  • Ответы JSON Spring Cloud Contract Producer являются статическими, так как потребитель будет сравнивать с одним и тем же навсегда. Если производитель собирается предоставить ответ JSON на основе учетной записи с несколькими возможными комбинациями наборов данных,тогда Потребитель также должен вызвать Службу через Заглушки с тем же входом Учетной записи, в противном случае он отправляется в Fail. Потребитель не собирается подключаться к какой-либо Базе данных, а просто сравнивает JSON в Заглушках с жестко закодированным ответом на стороне Потребителя..

Приятно иметь

Производитель / Потребитель должен иметь возможность подключаться к одной и той же или к различным базам данных и динамически переключать входные данные запроса, что делает интеграционное тестирование с использованием SpringОблачный контракт более надежный.

Случай: рассмотрим банковский счет с информацией о владельце совместного счета.Производитель предоставляет Микро Сервис, который предоставляет Потребителю информацию об Учетной записи.Сегодня г-н Боб имеет учетную запись без какой-либо информации о владельце совместного счета.Производитель генерирует заглушки и связывается с 10 потребителями.Завтра г-н Боб хочет добавить свою супругу г-жу Лили в качестве совместного владельца счета.Теперь Producer генерирует заглушки и связывается с 10 потребителями.Из которых 3 Потребителям не требуется информация о Совместном счете, но 7 из них строго зависят от полной информации.

Во-первых, все 10 Потребителей должны будут переписать контрольные примеры с их конца, так какИнтеграционный тест завершается неудачей, потому что он возвращает дополнительную информацию, но поскольку потребители статически сравнивают ответ с жестко заданным значением / подписью.

...