목차
ATDD에 대한 오해
•
인수 테스트로 시작하는 TDD
ATDD란?
프로젝트에 참가하는 팀원들은 개발자만 있는것이 아니라 기획자, 테스터 등 각각 다른 배경지식과 관점을 가진 사람들이 함께하는데, 이런 다른 관점의 팀원들간에 협업을 위한 애자일 방법중 하나다.
하나의 주제를 가지고 팀원들이 생각을 한다고 하더라도 모두가 각각의 배경지식으로 결과물을 상상하기에 결과물은 네모, 세모, 동그라미로 각각 다를 수 있다. 그렇기에 이 프로젝트의 결과물이 나오는시점에서 각각 생각한것과 다른 결과물에 트러블이 생길 수 있다.
ATDD는 이러한 문제를 해결하기위해 기획 단계부터 인수 테스트를 통해 공통의 이해를 도모해 프로젝트를 진행하는 방법이다.
그렇기에 인수테스트(Acceptance Test)는 요구사항을 작성하는데에 집중한다.
ATDD 프로세스
1.
User Story
•
who, why, what을 기준으로 작성하며 결과물은 User Story다.
2.
Discuss
•
User Story를 바탕으로 인수조건을 작성하며 인수조건은 사용자의 단어로 작성되어야 한다.
•
인수 조건은 기능 완료 조건으로 사용자 스토리보다 조금 더 구체적인 시나리오를 통해 기술한다.
•
결과물은 인수조건
Feature: 최단 경로 구하기
Scenario: 지하철 최단 경로 조회
Given 지하철역들이 등록되어 있다.
And 지하철노선이 등록되어 있다.
And 지하철노선에 지하철역들이 등록되어 있다.
When 사용자는 출발역과 도착역의 최단 경로 조회를 요청한다.
Then 사용자는 최단 경로의 역 정보를 응답받는다.
Plain Text
복사
3.
Distill
•
도출된 인수 조건을 통해 인수 테스트를 작성한다.
•
인수 테스트는 사용자의 관점이며 시스템 작동 방식을 설명하기 위해 요구 사항의 형태로 작동하며 시스템이 의도한대로 작성하는지 확인하는 방법으로도 사용된다.
•
테스트 방식은 Given-When-Then 형식이다.
•
인수테스트 작성기준은 팀에서 결정한다.
@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
public class LineAcceptanceTest {
@DisplayName("최단 경로 구하기")
@Test
void findPath() {
...
}
Plain Text
복사
4.
Develop
•
문서화
◦
이 때, 문서화의 기준은 팀에서 결정한다.
•
TDD로 개발
◦
인수 테스트를 기준으로 하나씩 기능 개발을 진행한다.
◦
TDD 프로세스에 따라 테스트케이스 작성 후 프로덕션 코드 작성
◦
Outside In / Inside Out 방향으로 개발한다.
•
결과물: 소프트웨어 결과물
5.
Demo
•
인수 테스트가 성공하면 해당 이슈는 완료된다.
•
완료된 인수 테스트 수에 따라 개발 진행상황을 확인할 수 있다.
