보통 ATDD하면 TDD를 가장 먼저 떠올릴 것이다
TDD란 짧은 개발 사이클을 반복하는 프로세스로서 다음과 같은 사이클을 가진다.
- 실패하는 테스트 코드를 만든다.
- 테스트를 통과하게 한다.
- 이를 리팩토링 한다.
TDD에서 테스트 코드의 역할은 검증의 역할보다는 내가 구현할 기능의 명세 즉 요구사항의 명세라고 이 강의에서는 말한다. ATDD에서 인수테스트 코드의 역할 또한 이와 일맥상통하는 부분이 있다.
ATDD란
인수 테스트는 고객과 개발자, 그리고 테스터간의 커뮤니케이션을 기반으로한 개발 방법론이다.
이러한 프로세스는 개발자와 테스터가 구현 전에 고객의 요구를 이해하는 데 도움이되며 고객이 자신의 도메인 언어로 대화할 수 있도록 한다.
위의 그림에서 알 수 있듯이 ATDD의 사이클은 거대하다.
TDD랑 비슷하다고 생각해서 접근하다보면 그렇지 않음을 금방 알게 된다.
ATDD에는 유저스토리, 시나리오 테스트등 애자일과 관련된 내용이 있기 때문이다.
ATDD의 사이클은 이렇듯 거대하지만 이번 수업에서는 ATDD 전체 프로세스 보다는 개발 부분에 집중해서 강의를 할 예정이라 한다. 즉 ATDD라는 도구를 개발에서 어떻게 적용할 수 있을지에 집중해서 강의를 한다고 한다.
개발관점에서 ATDD 사이클은 위와 같다.
인수테스트를 먼저 한 다음 세부적인 기능에 대한 TDD를 진행하는 것이다.
인수테스트란
[테스트 주도 개발로 배우는 객체 지향 설계와 실천]
우리는 기능을 구현할 때, 만들고자 하는 기능을 수행하는 인수 테스트를 작성하는 것으로 시작한다. 인수테스트가 실패하는 동안은 시스템이 아직 그 기능을 구현하지 않고 있다는 것을 보여준다. 인수 테스트가 통과되면, 기능구현은 끝이다.
ATDD는 요구사항을 인수테스트로 명세해서 구현을 하는데, 이 때 요구사항의 형식이 시나리오 형식이다. 인수 조건이란 시스템이나 구성 요소가 acceptance(인수)되기 위해 충족해야 하는 기준을 의미한다. (인수란 받아들여짐, 수락되어짐이란 뜻으로 고객이 받아들인다 라고 생각하면 될 듯하다)
인수테스트는 어떤 테스트의 종류인가?
인수테스트는 API 테스트?
인수테스트는 E2E 테스트?
인수 테스트는 통합 테스트?
인수 테스트는 테스트의 의도(목적)에 따라 구현 방법이 달라진다.
[린 애자일 기법을 활용한 테스트 주도 개발]
인수 테스트의 개념은 테스트 의도에 따라 정해지는 것이지 테스트를 어떻게 구현하는지에 따라 정해지는 것이 아니다. 유닛 레벨이나 통합 레벨, 사용자 인터페이스 레벨에서 인수테스트를 적용할 수 있다. ... 더 나아가, 인수 테스트를 유닛이나 컴포넌트가 의도한 동작을 하는지 확인하는 설계 검증 테스트로 사용할 수 도 있다. 어떤 경우든 인수 테스트는 사용자에게 어플리케이션이 인도될 수 있는지를 확인한다.
시나리오 형태로 내가 원하는 요구사항을 잘 동작하는지를 확인할 수 있으면,
그게 단위테스트가 되었던 통합테스트가 되었던 API테스트가 되었던 상관없이 인수테스트라고 부를 수 있다.
인수테스트 요약
- 작업의 요구사항을 만족시켜 작업의 끝을 검증하는 테스트
- 이 때, 요구사항은 Acceptance Criteria(인수 조건)라고 부른다.
- 인수 조건은 사용자 스토리를 시나리오 형식으로 표현한 것이다.
ATDD를 하는 이유
1. 나는 나를 믿지 못한다.
기능을 한참 구현하다가 점심시간이 된다거나 퇴근시간이 되면 흐름이 끊기게 된다.
흐름이 끊긴 후 다시 작업을 할 때 어디서부터 어디까지 구현했는지 기억하리라는 보장이 없다.
그래서 인수테스트를 돌려가면서 '아 내가 여기까지 구현했구나'를 파악한다고 한다.
또한 인수테스트가 통과한다면 이 부분에 대해서는 완벽하게 구현한 것이므로 넘어갈 수 있는 근거가 된다고 한다.
2. 나는 빠른 피드백을 받고 싶다.
굳이 배포를 하지 않더라도 빠르게 피드백을 받는 용도로 사용하고 있다.
3. 일의 효율성이 증가한다.
인수테스트라는 명확한 기준이 있으면 내가 해야할 일에 대해 명확하게 파악할 수 있기 때문에
'아차 내가 이걸 구현안했구나'의 횟수가 줄어들었다고 한다.
4. 나는 게으르다.
기능 구현을 하기전에 문서화한다거나 테스트 시나리오를 만드는 것이 귀찮았다고 한다.
그런데 인수테스트 기반의 기능구현을 하다보면 인수테스트 자체가 문서화 되기도 하고,
ATDD 사이클 내에 문서화라는 단계를 넣으면 자동으로 기능개발이 끝난상태에서 문서화와 시나리오 테스트가 갖추어진 상태로 기능개발이 끝나게 된다.
첫째주차의 과정에서 인수 테스트
- 백엔드 개발자가 단독적으로 적용해서 실천해볼 수 있는 범위
- 고객은 프론트엔드 개발자 혹은 API를 활용하는 사람 대상
- API 접점에서 검증하는 E2E 테스트
- API의 Request와 Response 정보 이외에 내부 정보는 최대한 가리는 블랙박스 형식의 테스트
블랙박스 형식의 테스트란?
- 클라이언트는 결과물의 내부 구현이나 사용된 기술을 기반으로 검증하기 보다는 표면적으로 확인할 수 있는 요소를 바탕으로 검증하려 한다.
- 실제 사용하는 상황의 시나리오를 바탕으로 요구사항을 작성
- 내부 구현이나 기술에 의존적이지 않는 테스트
E2E 테스트란?
Endpoint to Endpoint 테스트로 사용자의 입장에서 테스트하는 것을 의미한다.
페이지에서 원하는 텍스트가 제대로 출력이 되었는지, 버튼을 클릭했을 때 올바른 동작을 수행하는 지 등을 테스트한다. 즉 사용자에게 직접 노출되는 부분을 점검한다고 생각하면 될 듯하다.
※ 엔드포인트
API가 서버에서 자원(Resource)에 접근할 수 있도록 하는 URL을 의미한다.
API 레벨의 블랙박스 테스트이므로 요청과 응답을 기준으로 하는 API레벨의 E2E 테스트로 검증한다.
