💡 Intro

ATDD는 TDD만큼 효율을 낼 수 있는 도구다 ?!

• ATDD는 모든 문제를 해결할 수 없다.
  ATDD뿐만 아니라 모든 도구는 모든 문제를 해결하는 만능 열쇠는 아니다.
  상황에 맞춰 사용하는 것일 뿐!

개발하다가 길을 잃은 적이 있다면 ...
요구사항을 잘못 이해한 적이 있다면 ...
이럴 때 올바른 요구사항을 가리키는 등대가 있었다면 ?

ATDD를 통해 효율적인 개발 프로세스를 경험할 수 있다.

💡 인수 테스트

인수 테스트는 API / E2E / 통합 테스트야?
인수 테스트는 테스트의 의도에 따라 구현 방법이 달라진다.

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

어떻게 구현하는지에 따라 정해지는 것이 아니라 테스트 의도에 따라 정해지는 것
내가 생각한 시나리오대로 동작하는지를 검증하는 것
백엔드 개발자가 단독 적용해서 실천해볼 수 있는 범위
고객은 프론트엔드 개발자 또는 API 활용하는 사람
API 접점에서 E2E 테스트
블랙 박스 테스트의 성격을 가지고 있음

블랙 박스 테스트

• 클라이언트는 결과물의 내부 구현이나 사용된 기술은 몰라도 됨
• 표면적으로 확인할 수 있는 요소를 바탕으로 검증
• 실제 사용하는 상황의 시나리오를 바탕으로 요구사항 작성
• 내부 구현이나 기술에 의존적이지 않음

💡 인수 테스트 주도 개발

A + TDD
테스트가 가능한 요구사항으로 소프트웨어를 개발하는 프로세스
요구사항을 검증하는 테스트 == 인수 테스트

TDD와 차이점

TDD : 작은 단위의 요구사항을 테스트하고 구현함
ATDD : 시나리오 형태의 요구사항을 테스트하고 구현함
등대를 만든다는 관점에서는 비슷함

왜 함?

생산성이 두 배 증가한다.
명확한 시작과 끝을 제시한다.
직접 동작하는 테스트를 만듦으로써 문서보다 신뢰도가 높다.
배포하고 눌러보는 일련의 과정 스킵, 피드백을 빨리 받을 수 있다.
귀찮은 작업을 프로세스로 강제한다. (테스트, 문서화 등)
인수 테스트가 실패하는 동안은 기능이 구현되지 않은 것. 인수 테스트가 성공하면 기능 구현은 끝이다.

💡 도구들

@SpringBootTest

테스트에 사용할 ApplicationContext를 쉽게 지정하게 도와줌

webEnvironment

• 테스트 서버의 실행 방법 설정
• MOCK(기본값) : Mocking된 웹 환경 제공, MockMvc를 사용한 테스트 진행
• RANDOM_PORT : 실제 웹 환경 구성
• DEFINED_PORT : 실제 웹 환경 구성, 지정 포트 listen
• NONE : 웹 환경 구성 X

RestAssured

REST API의 테스트와 검증을 단순화하도록 설계
HTTP 작업에 대한 검증을 위한 API 활용 가능
given - when - then 으로 나뉨

given

요청을 보내기 전 필요한 것을 설정

when

요청을 어디다 보낼지 설정

then

응답을 어떻게 할 건지 설정

JsonPath

JSON 문서를 읽기 쉽게 도와주는 자바 DSL

$..author, $.store.book[*]