[ATDD] 인수 테스트

 

보통 xxx 주도 개발 시리즈에서 가장 유명한 개발 방법론이 TDD (Test Driven Development)이다.

 

나도 Console 기반의 어플리케이션을 만드는 과정에서는 시간만 된다면 TDD를 거의 의식적으로 수련하려 노력하며,

API 기반의 SpringBoot 환경에서도, Service부분이나 Controller에서 TDD를 적용하려 노력한다.

 

하지만 기존 나의 Spring Test 방식에는 부족한 부분이 많다 생각하였고, 따라서 ATDD(인수 테스트 기반 개발방법론)기반의 SpringBoot 테스트를 학습하려 찾아다니게 되었다 ㅎㅎ

 

이번 한달동안은 ATDD의 바다에 스스로를 던져보는 시간이 될 것 같다.

 

1. TDD vs ATDD

둘간에 차이점은 무엇일까? 뭐가 다른 것 일까?

출처 - Next Step 류성현

TDD나 ATDD나 test 코드가 단순 검증의 역할 이전에 명세의 역할을 한다는 점은 똑같다.

다만 차이점은, 대상이 작은 기능 단위 인지? 사용자 시나리오 형태의 큰 범위의 기능인지? 에 따라 나뉠 것 이다.

 

2. ATDD 란?

2-1) ATDD 의 Cycle

인수 테스트는 고객과 개발자, 그리고 테스터간의 커뮤니케이션을 기반으로한 개발 방법론이다.
이러한 프로세스는 개발자와 테스터가 구현 전에 고객의 요구를 이해하는 데 도움이되며 고객이 자신의 도메인 언어로 대화할 수 있도록 한다.

 

출처 - Next Step 류성현

 

이렇게 방대한 ATDD 사이클을 처음부터 수련하기에는 무리가 있다.

작은 부분부터 의식적으로 수련해 나아가야 한다.

 

따라서 ATDD의 전체 프로세스 보다는 개발 부분에 집중하여 수련하게 될 거라 하셨다.

 

ATDD는

1) 테스트가 가능한 요구사항으로 소프트웨어를 개발하는 프로세스 이다. 

2) 요구 사항을 검증하는 테스트로 소프트웨어를 개발하는 프로세스 이다.

3) 인수 테스트로 소프트웨어를 개발하는 프로세스 이다.

 

1,2,3 의 주황 글씨가 사실상 같은 의미이다.

 

2-2) ATDD를 하는 이유?

1. 작업의 시작과 끝이 명확해 진다.

모호한 도메인이 주어지고, 요구사항을 명세해야 한다면, 일단 인수테스트 부터 만드는 걸로 시작한다. (명확한 시작지점)

 

2. 구현한 기능을 배포하지 않고 테스트로 확인할 수 있다.

거의 대부분의 경우 배포를 하지 않고 테스트 상에서 검증을 끝마칠 수 있다.

 

3. 귀찮은 작업 프로세스로 강제화

테스트 코드 작성과 문서화는 원래 귀찮은 작업이기는 하다.

다만 전체 기능을 검증하는 테스트가

 

3. 인수테스트?

Agile 에서의 Acceptance Test는 사용자 스토리(요구사항)을 검증하는 기능 테스트를 의미한다.

 

이 말을 처음 들으면 "??? 뭔소리지 ???" 부터 떠오른다...

 

즉, 요구사항을 정리해서 사용자 Story를 만들고, 이를 통해 검증하겠다는 것 인데?

요구사항을 ---정리---> User Story

아니 그러면 왜 이름이 "User Story Test" 가 아니고, "Acceptance Test" 라고 부를까?

 

1. 소프트웨어 밖의 영영

원래 소프트웨어 이외의 영역에서 Acceptance Test는 마지막 단계에서 제시했던 요구사항이 충족되는지 확인하는 테스트를 의미한다.

실제로 운영하기에 앞서 기능과 성능의 적합성 여부를 살펴보는 테스트 인 것이다.

 

2. 소프트웨어 안의 영역

소프트웨어의 세상에서는 Acceptance 가 "수락" 한다는 의미에서 인수로 해석되었다.

즉, 마지막 단계에서 수락 하기 전에 수행하는 테스트 이기 때문에 Acceptance Test가 된 것 이다.

 

이름 좀더 쉽게 바꾸면,

 

작업을 종료 시켜도 되는지 검증하는 테스트를 Acceptance Test (인수 테스트) 라고 부른다.

 

[테스트 주도 개발로 배우는 객체 지향 설계와 실천]
우리는 기능을 구현할 때, 만들고자 하는 기능을 수행하는 인수 테스트를 작성하는 것으로 시작한다.
인수테스트가 실패하는 동안은 시스템이 아직 그 기능을 구현하지 않고 있다는 것을 보여준다. 
인수 테스트가 통과되면, 기능 구현은 끝이다.

 

4. API 개발을 위한 시나리오 기반 인수테스트 만들기

다음 코드는 API 단위 테스트 일까? 인수테스트 일까?

출처 - Next Step 류성현

사실 형식만 두고 보면 구별하기 힘들수도 있다.

 

다만 Acceptance Test라면 사람이 경로조회를 하기 위해서 사용자의 시나리오를 만들어야 한다.

예를 들어,

1) 지하철 역 생성

2) 노선 생성

3) 역간에 구간 설정

4) 출/도착역을 입력할시

5) 결과로 경로 목록이 나온다.

 

위 과정에서 시나리오가 생겼다. 즉 인수조건이 있다.

이러한 일련의 시나리오를 검증하는 테스트를 Acceptance Test(인수 테스트) 라고 부른다.

 

만약 그냥 API 단위 테스트 였다면, API 요청 하나하나가 잘 동작하는지만 확인하고 끝났을 것 이다.

 

5. 인수테스트는 어떤 테스트의 종류인가?

인수테스트는 API 테스트?
인수테스트는 E2E 테스트?
인수 테스트는 통합 테스트?

 

인수 테스트는 테스트의 의도에 따라 구현 방법이 달라진다.

 

인수 테스트는 요구사항을 만족하는지 검증하는 테스트 라고 위에서 언급한적이 있다.

하지만 "요구사항" 이라는 것 이 API level 이라고는 적혀있지 않다.

그럼 뭐 Console 기반의 환경에서는 인수테스트가 불가능 할까? 절대 아니다. 콘솔 환경도 가능하다.

 

따라서 인수테스트 에서는 어떤 부분을 검증하는가 에 따라서 구현 방법이 달라진다.

 

[린 애자일 기법을 활용한 테스트 주도 개발]
인수 테스트의 개념은 테스트 의도에 따라 정해지는 것이지 테스트를 어떻게 구현하는지에 따라 정해지는 것이 아니다.
유닛 레벨이나 통합 레벨, 사용자 인터페이스 레벨에서 인수테스트를 적용할 수 있다.
... 더 나아가, 인수 테스트를 유닛이나 컴포넌트가 의도한 동작을 하는지 확인하는 설계 검증 테스트로 사용할 수 도 있다.
어떤 경우든 인수 테스트는 사용자에게 어플리케이션이 인도될 수 있는지를 확인한다.

시나리오 형태로 내가 원하는 요구사항을 잘 동작하는지를 확인할 수 있으면,
그게 단위테스트가 되었던 통합테스트가 되었던 API테스트가 되었던 상관없이 인수테스트라고 부를 수 있다.

 

6. Acceptance Test 요약

• 작업의 요구사항을 만족시켜 작업을 종료해도 되는지 검증하는 테스트
• 이 때, 요구사항은 Acceptance Criteria(인수 기준)라고 부른다.
• 인수 기준을 구체화 한것을 인수 조건 이라 부른다.
• 인수 조건은 사용자 스토리를 시나리오 형식으로 표현한 것이다.