Использование Spring Cloud Contract для тестирования взаимодействия интерфейса с сервером

Я хотел бы использовать Spring Cloud Contract (https://spring.io/projects/spring-cloud-contract), чтобы протестировать взаимодействие внешнего интерфейса с сервером: особенно, чтобы отловить такие ошибки, как 400 ошибки http.

Я смог запустить свои заглушки с помощью бегуна заглушек Spring Cloud Contract. Однако я заметил, что когда фактический бэкэнд возвращал 400, работающие заглушки возвращали 404 ошибку not found.

Вот мой контракт:

description: |
    Signup use case
    ```
    given:
       a user signs up
    when:
       the sign up request is valid
    then:
       the user is signed up
     ```
request:
    method: POST
    url: /api/signup
    body:
        userAccountType: PARENTS
        email: [email protected]
        firstName: John
        plainPassword: secret
        address:
            placeId: 'an_id'
            description: '10 Downing Street'
    headers:
        Content-Type: application/json
response:
    status: 200

Если мой интерфейс (то есть Angular) просто выдает Http POST с, скажем, отсутствующим полем email, тогда я ожидаю, что работающие заглушки вернут 400.

Я был бы признателен, если бы кто-нибудь поделился лучшими практиками или советами, чтобы лучше использовать Spring Cloud Contract для тестирования внешнего и внутреннего интерфейса.


person balteo    schedule 07.08.2019    source источник
comment
Если вы получили 404, это означает, что WireMock не может найти заглушку. Это означает, что ваш запрос не соответствует заглушке WireMock.   -  person Marcin Grzejszczak    schedule 07.08.2019
comment
Я понимаю. Но тогда как я могу гарантировать, что мой потребитель (здесь интерфейс) не отправляет недопустимые запросы к моему API производителя, что приведет к 400? Должен ли я подписывать контракты (со статусом 400) для каждой из комбинаций недействительных запросов?   -  person balteo    schedule 07.08.2019
comment
Вы должны создать еще один контракт с отсутствующим полем и пометить его кодом состояния 400.   -  person Marcin Grzejszczak    schedule 07.08.2019
comment
Тогда контрактов с кодом статуса-400 будет столько же, сколько недействительных комбинаций запросов?   -  person balteo    schedule 07.08.2019
comment
Если это требование вашего бизнеса, то да. С помощью groovy вы можете извлечь большую часть настроек и вернуть список таких контрактов.   -  person Marcin Grzejszczak    schedule 07.08.2019
comment
Большое спасибо за ваш вклад.   -  person balteo    schedule 07.08.2019


Ответы (1)


Хотя я согласен с тем, что сказал Марцин в комментариях ...

Если вы получили 404, это означает, что WireMock не может найти заглушку. Это означает, что ваш запрос ›не был сопоставлен с заглушкой WireMock.

Вы должны создать еще один контракт [для каждого недействительного запроса] с [a] отсутствующим полем и ›пометить его кодом состояния 400

... может быть способ немного обмануть с помощью priority

Вы можете создать низкоприоритетный контракт для любого запроса, который попадает в правильный URL и возвращает 400. Само по себе это означает, что каждый вызов этого URL будет возвращать 400.

Затем создайте контракты, которые попадают в правильный URL с правильными параметрами, чтобы вернуть 200 и ожидаемый ответ, и установите для них высокий приоритет. Поскольку эти контракты перекрываются, приоритет гарантирует, что будет возвращено 200, а не 400.

Любой другой URL-адрес по-прежнему будет возвращать 404.

Отказ от ответственности: я на самом деле не пробовал это сам.

person Bradleo    schedule 26.06.2020