>맨땅에 코딩

ATDD 프로세스

29 November 2019 — Written by Boorownie
#ATDD#Agile

ATDD(Acceptance Test Driven Development)는, 용어를 그대로 풀어서 해석하면, 인수 테스트 주도 개발으로서 인수 테스트를 먼저 작성한 다음 기능 개발을 하는 방법입니다. 여기서 말하는 인수는 클라이언트가 요청한 소프트웨어의 결과물을 넘겨 받는다는 의미이며, 인수 테스트는 요구사항을 모두 만족하여 기능 완료 여부를 확인하는 테스트라고 할 수 있습니다.

단순히 인수 테스트를 만들기 위해 ATDD를 도입하는 것은 아닙니다. ATDD의 뜻을 찾아보면 사용자(고객)-개발자-테스터간의 커뮤니케이션을 기반한 개발 방법이라고 정의됩니다. 커뮤니케이션을 위해서 인수 테스트를 만든다는 뜻인데 이 둘의 연관관계를 연상하는 것이 어려울 수 있습니다. 이번 포스팅에서는 인수 테스트를 만드는 ATDD의 궁극적인 목표와 ATDD 프로세스를 예시를 통해 알아보도록 하겠습니다.

애자일 관점에서의 ATDD

애자일 방법론에서는 미리 예측하며 개발을 하지 않습니다. 일정한 주기를 가지고 끊임없이 프로토 타입을 만들어냅니다. 필요한 부분이 발생하면, 그때 기능 목록을 추가하고 수정하여 하나의 커다란 소프트웨어를 개발해 나갑니다.[link] 이러한 애자일의 프로그밍 방법론 중 하나인 ATDD는 사용자 스토리를 기반으로 인수 조건을 도출하여 기능 개발을 진행하는 방법론 입니다.

ATDD에서는 사용자(고객)-개발자-테스터, 즉 팀원들이 각 포지션의 관점으로 함께 논의하여 실행 가능한 예제를 도출합니다. 이러한 과정은 사용자(고객)들에게 요구사항을 명확히 하는데 도움을 주고, 개발자에게는 코드 구현의 방향성과 목적을 가지는데 도움을 주고, 테스터에게는 단순히 기능적 테스트를 하는 것 보다 좀 더 나은 계획을 세울 수 있게 도와줍니다. 결국 ATDD는 팀원간에 요구사항을 같은 수준으로 이해하는데 큰 도움을 줍니다. 요구사항이 무엇이고 기능 완료 기준이 무엇인지에 대해 하나의 공통된 생각을 가질 수 있게 합니다. 일정한 주기를 가지고 진행하는 "스프린트"에서는 이러한 공통의 기준들이 매우 중요합니다.[link]

즉, 스프린트에서는 팀원들이 공통의 기준을 가지고 진행하는것이 중요합니다. 사용자 스토리와 인수 조건, 인수 테스트 작성을 모든 개발 팀원이 함께 논의하여 요구사항에 대한 공통의 이해를 할 수 있게 도와줍니다.

ATDD 프로세스

ATDD는 4가지의 행위(Discuss, Distill, Develop, Demo)와 4가지의 산출물(User Story, Acceptance Criteria, Tests, Working Software), 하나의 결과(Business Value)로 설명할 수 있습니다.[link] ATDD Cycle을 바탕으로 서핑 용품 대여 서비스를 개발해 나가는 과정을 따라가며 ATDD 프로세스에 대해서 알아보겠습니다.

사용자 스토리 작성하기

  • 사용자 스토리는 who, why, what을 기준으로 작성합니다.[link]

  • 결과물: 사용자 스토리

    서핑샵 손님들은 서핑 용품을 빌리기 위해 대여 신청을 하고 싶다.

Discuss

  • 사용자 스토리를 바탕으로 예시만들고, 이를 통해 인수 조건을 도출합니다. 인수 조건 잘 도출하는 법
  • 인수 조건은 기능 완료 조건으로서 사용자 스토리 보다 조금 더 구체적인 시나리오를 통해 기술합니다.

  • 결과물: 인수 조건

    • 날짜별로 대여가 가능한 용품을 조회할 수 있어야 한다.
    • 대여를 희망하는 용품을 희망하는 날짜에 신청 할 수 있어야 한다.
    • 대여 신청한 내역을 사장님이 확인 할 수 있어야 한다.

Distill

  • 도출된 인수 조건을 통해 인수 테스트를 작성합니다.
  • 인수 테스트는 사용자의 관점을 나타내며 시스템 작동 방식을 설명하기 위한 요구 사항의 형태로 작동하며 시스템이 의도 한대로 작동하는지 확인하는 방법으로도 사용됩니다.
  • 테스트는 Given-When-Then 형식으로 작성을 하되 해당사항이 없는 부분은 생략할 수 있습니다.
  • 성공 케이스와 실패 케이스를 정의하고 요청/응답에 대한 DTO를 결정합니다.
  • 인수 테스트 작성의 기준은 팀에서 정합니다. (ex. 인수 테스트는 기능별로 만들고 Controller 테스트를 통해 에러 케이스를 검증한다.)

  • 결과물: 인수 테스트

    @DisplayName("날짜별로 대여가 가능한 용품을 조회할 수 있어야 한다.")
@Test
public void showItems() {
 this.webTestClient.get()
         .uri(uriBuilder -> uriBuilder.path("/items")
                 .queryParam("date", "20191127")
                 .build())
         .accept(MediaType.APPLICATION_JSON)
         .exchange()
         .expectStatus().isOk()
         .expectHeader().contentType(MediaType.APPLICATION_JSON)
         .expectBody()
         .jsonPath("$").isNotEmpty();
}

테스트 시나리오의 품질관리

기술적인 행위를 바탕으로 시나리오를 작성 할 경우 기술과 관련된 용어가 나타나고 구현과 관련된 기술이 바뀌거나 시스템을 사용하는 순서가 바뀌면 테스트 시나리오를 수정해야 합니다. 작업 흐름을 바탕으로 시나리오를 작성 할 경우 기술이 바뀌더라도 테스트 시나리오가 바뀌지 않지만, 작업 흐름이 변경되면 테스트 시나리오를 수정해야 합니다. 비즈니스 규칙을 명확히 드러나도록 테스트 시나리오를 작성하면 구현과 관련 기술이 변경되어도, 작업 흐름이 바뀌어도 테스트 시나리오를 변경하지 않아도 됩니다. [6]

Technical Activity
  1. 대여 가능한 용품을 조회할 수 있는 페이지로 접속한다.
  2. 조회하고자 하는 날짜를 "20191127"이라고 입력한다.
  3. 조회하기 버튼을 누른다.
  4. 결과 페이지에서 대여가능한 용품 목록을 확인한다.
Workflow
  1. 대여 가능한 용품을 조회할 수 있는 페이지로 접속한다.
  2. 조회하고자 하는 날짜를 2019년 11월 27일로 설정한다.
  3. 조회한다.
  4. 대여가능한 용품 목록 확인한다.
Business Rule
  • Scenario: 특정 일자에 대여 가능한 물품 정보를 제공한다.
  • When: 2019년 11월 27일 대여 가능한 물품을 조회한다.
  • Then: 2019년 11월 27일 대여 가능한 물품 목록을 확인할 수 있다.

Develop

  • 문서화

    • 벡엔드와 프론트의 작업을 병렬로 진행할 수 있도록 도움을 줍니다.
    • 문서화 할 기능의 기준은 팀에서 정합니다. (ex. 사이드 케이스 / 실패 케이스에 대해서는 내부항목으로 기재한다.)

  • TDD로 개발하기

    • 인수 테스트 기반으로 하나씩 기능개발을 진행합니다.
    • TDD 프로세스에 따라 테스트를 먼저 작성하고 프로덕션 코드를 작성합니다.
  • 결과물: 소프트웨어 결과물

Demo

  • 인수 테스트가 성공이 되면 해당 이슈는 완료합니다. (애자일에서는 검증 단계가 필요 없을까?)
  • 완료된 인수 테스트 수에 따라서 개발 진행 상황을 인지할 수 있습니다.
←ATDD with Spring Boot