토리맘의 한글라이즈 프로젝트 logo 토리맘의 한글라이즈 프로젝트

스프링 클라우드 컨트랙트 공식 레퍼런스를 한글로 번역한 문서입니다.

전체 목차는 여기에 있습니다.


스텁stub에서 가장 중요한 것 중 하나는 재사용 가능 여부라고 할 수 있다. 스텁stub이 의미가 있으려면 폭넓게 사용할 수 있어야 한다. 하지만 요청과 응답을 하드코딩하면 (날짜나 ID등) 보통 재사용하기가 어려워진다. 아래 있는 JSON 요청을 생각해 보자:

{
    "time" : "2016-10-10 20:10:15",
    "id" : "9febab1c-6f36-4a0b-88d6-3b6a6d81cd4a",
    "body" : "foo"
}

이제 아래 JSON 응답을 살펴보자:

{
    "time" : "2016-10-10 21:10:15",
    "id" : "c4231e1f-3ca9-48d3-b7e7-567d55f0d051",
    "body" : "bar"
}

(데이터베이스에서 이 컨텐츠를 생성한다고 가정하고) time 필드에 적당한 값을 설정하기 위해 시스템 시간을 변경하거나, 데이터를 생성하는 쪽에서 스텁stub 구현체를 제공한다고 생각해보자. 굉장히 번거로운 작업이 아닐 수 없다. id 필드도 마찬가지다. UUID generator로 스텁stub 구현체를 하나 만들 수도 있지만 이렇게 하는 건 의미가 없다.

컨슈머consumer라면, 시간이나 UUID 값을 뭘로 보내든 요청이 매칭되길 바랄 거다. 이게 가능하다면 시스템이 평소처럼 데이터를 생성하기 때문에, 별도로 고정된 스텁stub을 만들지 않아도 된다. 앞에서 보여준 JSON의 경우, body 필드가 가장 중요한 부분이라고 가정해 보자. 즉, 이 필드 값에만 집중하고 다른 필드에는 매칭 조건을 제공하는 방법이 있다. 즉, 컨슈머consumer는 스텁stub이 다음과 같이 동작하기를 바란다:

{
    "time" : "SOMETHING THAT MATCHES TIME",
    "id" : "SOMETHING THAT MATCHES UUID",
    "body" : "foo"
}

컨슈머consumer 입장이라면, 응답에는 구체적인 값이 있어야 로직을 실행할 수 있다. 따라서 다음과 같은 JSON이 필요하다:

{
    "time" : "2016-10-10 21:10:15",
    "id" : "c4231e1f-3ca9-48d3-b7e7-567d55f0d051",
    "body" : "bar"
}

앞에서는 명세contract로부터 테스트 코드를 생성하는 과정이었다. 반면 프로듀서producer 입장에서는 상황이 많이 달라진다. 이번에는 정의한 명세contract를 파싱하고, 테스트에서 엔드포인트에 실제 요청을 전송하려 한다. 따라서 프로듀서producer 입장에선, 요청에 어떤 종류의 매칭 조건도 허용하기 어렵다. 프로듀서producer의 백엔드 로직이 동작하려면 구체적인 값이 필요하다. 따라서 다음과 같은 JSON이 필요하다:

{
    "time" : "2016-10-10 20:10:15",
    "id" : "9febab1c-6f36-4a0b-88d6-3b6a6d81cd4a",
    "body" : "foo"
}

반면 명세contract의 유효성 관점에서 보면, 응답에 반드시 time이나 id에 대한 구체적인 값을 포함할 필요는 없다. 프로듀서producer 입장에서 이런 값들을 생성한다고 생각해 보자. 다시 말하지만, 항상 고정된 값을 반환해야 한다면 매번 스텁stub을 따로 만들어야 한다. 그렇기 때문에 프로듀서producer 측에서는 다음과 같은 응답을 원할 거다:

{
    "time" : "SOMETHING THAT MATCHES TIME",
    "id" : "SOMETHING THAT MATCHES UUID",
    "body" : "bar"
}

그렇다면 어떻게 컨슈머consumer에게는 매칭 조건을, 프로듀서producer에게는 구체적인 값을 제공할 수 있을까 (또는 그 반대로 설정하려면)? Spring Cloud Contract를 사용하면 동적인 값을 설정할 수 있다. 즉, 통신하는 양쪽에서 서로 다른 값을 사용할 수 있다는 뜻이다.

자세한 내용은 Contract DSL 섹션에서 확인할 수 있다.

요청과 응답 body를 올바르게 구성하는 방법을 이해하려면 Groovy의 JSON 관련 문서를 읽어봐라.


Next :
7.4. 스텁 버전은 어떻게 관리해야 하나요?
스텁의 버전 관리

전체 목차는 여기에 있습니다.

<< >>

TOP