[ATDD] 1. ATDD(Acceptance Test Driven Development)

목차

1. TDD(Test Driven Development) : 테스트 주도 개발

2. ATDD(Acceptance Test Driven Development) : 인수 테스트 주도 개발

3. 단위 테스트 vs 통합 테스트 vs 인수 테스트

4. ATDD 학습 방법

 

 

 

전체 코드 확인

 

1. TDD(Test Driven Development) : 테스트 주도 개발

1) 실패하는 테스트 코드 작성

2) 테스트를 성공시키기 위한 최소한의 프로덕션 코드 작성

3) 프로덕션 코드 리팩토링

 

테스트 코드를 먼저 작성하고 프로덕션 코드를 작성하는 이유는

단위 테스트에서 테스트 코드가 기능 검증의 역할 보다

테스트 할 단위에 대한 요구사항을 명세하는 역할이 더 크기 때문이라고 할 수 있다.

 

2. ATDD(Acceptance Test Driven Development) : 인수 테스트 주도 개발

TDD와 ATDD는 요구사항을 명세하고 기능을 구현하는 개발 방식은 동일하다.

다만, 요구사항의 형태가 다른데 ATDD에서는 시나리오 형태의 요구사항을 작성한다.

 

인수 테스트(Acceptance Test)란

사용자의 관점에서 올바르게 작동하는지를 검증하는 방법이다.

때문에 인수 조건은 기술용어가 사용되지 않고 일반 사용자들이 이해할 수 있는 단어(도메인 언어)를 사용한다.

인수 조건을 시나리오 형태의 사용자 스토리로 만들어 테스트가 통과하는지를 검증한다.

 

인수 테스트 기반 구현 프로세스

 

1) 인수 조건(요구사항)을 시나리오 형식으로 만든다.

2) 인수 테스트 코드를 작성한다.

3) 프로덕션 코드를 작성한다.

 

• 인수 조건 예시

CRUD에 대한 각각의 인수 테스트를 하나로 통합하는 방식으로 리팩터링을 진행할 수도 있다.

인수 테스트 통합 

 

ATDD의 목적

개발을 진행하기 이전에 고객, 개발자, 테스터가 충분한 논의를 통해 함께 요구사항을 적립하고

테스트 할 수 있는 명확한 요구조건을 만들도록 하여 서로의 의도와 다른 결과물이 나오는 것을 방지한다.

명확한 요구사항과 인수 테스트를 통한 빠른 피드백으로 공통의 이해를 도모해 프로젝트를 진행하도록 한다.

 

3. 인수 테스트의 가독성

인수 테스트는 사용자의 관점에서 인수 조건을 시나리오 형태로 만들어 검증하는 방식이기 때문에

구체적인 행위 보다는 목적이 뚜렷하게 드러나도록 하는 것이 좋다.

 

인수 테스트의 가독성을 높여주는 방법

메소드 분리, CRUD 추상화, BDD도구 사용 등으로 리팩토링

1) 의도 드러내기 : 한글 메소드 활용

2) 스텝 메소드(Given, When, Then)들을 static 선언하여 별도의 클래스로 분리(결국 Cucumber같은 BDD 도구가 필요해짐)

3) BeforEach를 활용해 중복 코드 제거

 

• 한글 메소드 예시

• 스텝 메소드 예시

 

4. 단위 테스트 vs 통합 테스트 vs 인수 테스트

인수 테스트의 개념은 테스트 의도에 따라 정해지는 것이지 테스트를 어떻게 구현하는지에 따라 정해지는 것이 아니다.

인수 테스트는 단위, 통합 테스트 등 어떤 레벨에서도 인수 테스트를 적용할 수 있다.

 

• 단위 테스트 : 구현한 부분, 단위를 검증
• 통합 테스트 : 각 단위들이 유기적으로 잘 동작하는지 검증
• 인수 테스트 : 요구사항을 만족하는지를 검증

 

5. 테스트 비용

인수 테스트는 반드시 확인해야할 인수 조건에 한해 검증하는 것에 집중한다.

나머지 데이터 검증, 예외 검증 등은 단위 테스트 등으로 확인할 수 있다.

 

6. ATDD 학습 방법

백엔드 개발자의 입장에서 ATDD를 단독으로 실천하기 위해서 인수 테스트의 의도를

고객을 프론트엔드 개발자 혹은 API를 활용하는 사람을 대상으로 한 E2E 테스트(API 접점에서 검증)로 정한다.

API의 Request와 Response 정보 이외 내부 정보는 최대한 가리는 블랙박스 형식의 테스트를 통해 ATDD를 경험해 볼 수 있다.

 

블랙박스 테스트란

내부 구현이나 기술에 의존적이지 않은 테스트로 내부 코드가 변경되더라도 테스트가 쉽게 깨지지 않도록 한다.

 

 

 

 

 

출처

nextstep - ATDD와 함께 클린 API로 가는 길