[ATDD] 1주차 강의

무엇보다 학습하는 습관 및 버릇을 들이자.

과정 소개

ATDD 과정 소개

• 인수 테스트 기반의 웹 API 기능 구현 경험
• 웹 프로젝트 레벨의 TDD 경험
• 스프링 기반의 테스트 도구 학습
• 코드 리뷰 프로세스 경험

기대 효과

• 인수 테스트 기반으로 TDD를 할 수 있다.
• 테스트를 효과적으로 리팩터링하여 유지보수를 잘 할 수 있다.
• 새로운 프로젝트 뿐만 아니라 레거시 코드에서도 TDD를 할 수 있다.
• 남들에게 TDD와 ATDD가 실무에서 가능하다고 설명할 수 있다.

무엇을 어떻게 학습할까?

• 요구사항 -> 문서화 -> 인수테스트 -> TDD -> API 개발 -> 테스트 리팩터링
• 인수테스트들을 어떻게 관리할지도 생각해볼수 있다.

도메인 설명

ATDD Intro

ATDD 이야기를 하기 전에

• ATDD는 모든 문제를 해결할 수 없다.
• 필요와 상황에 따른 도구로 사용된다.
  - 개발하다 방향을 잃은적, 요구사항을 잘못 이해한적 => 올바른 요구사항을 가리키는 등대가 있었다면...
  
• 테스트케이스가 요구사항 명세서가 된다.

ATDD란?

- 테스트가 가능한 요구사항으로 소프트웨어를 개발하는 프로세스
  => 인수 테스트로 소프트웨어를 개발하는 프로세스

TDD : 작은 단위의 요구사항

ATDD : 시나리오 형태의 요구사항 (인수 테스트)

ATDD를 하는 이유 

• 생산성 증가
  => 구현전에 인수 테스트를 수행하는 경우 팀의 생산성이 두 배가 되는 것을 확인했다.
• 작업의 명확한 시작과 끝을 제시
• 빠른 피드백
  - 구현한 기능을 배포하지 않고 테스트로 확인 가능
• 귀찮은 작업 프로세스로 강제
  - 테스트 코드 작성과 문서화는 귀찮은 작업
  - 전체 기능을 검증하는 테스트가 만들어짐
  - 회귀 테스트 역할을 수행
    - 회귀 테스트: 이미 테스트된 프로그램의 테스팅을 반복하는 것으로, 결함 수정 이후 변경의 결과로 새롭게 만들어 지거나, 이전 결함으로 인해 발견되지 않았던 또 다른 결함을 발견하는 테스트

인수 테스트

인수 테스트란?

• 사용자 스토리를 검증하는 기능 테스트
• 사용자 스토리로 테스트할 시나리오를 지정
• 명세나 계약의 요구 사항이 충족되는지 확인하기 위해 수행되는 테스트
• 소프트웨어 이외 다른 분야에서도 사용되는 용어
• 보통 마지막 단계에서 수행하는 테스트를 의미
• 작업을 종료 시켜도 되는지 검증하는 테스트
• 이 테스트가 성공하면 작업 끝!

테스트 종류

• 단위 테스트, 통합 테스트, E2E 테스트

콘솔 애플리케이션 개발을 위한 시나리오 기반 인수테스트 만들기 (로또)

• 시나리오 테스트를 작성할때 , 가장 짧은것(쉬운것) 부터 선택한다 (도메인의 이해에 따라 다름)

API 기반 ~ ( 지하철역 관리 기능 구현하기)

• RestAssured 라이브러리 사용

인수 테스트는 테스트의 의도에 따라 구현 방법이 달라진다.
- 단위테스트, api 테스트 등이 아님

테스트가 검증하는 대상

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

이번 과정에서의 인수 테스트

• 백엔드 개발자가 단독적으로 적용해서 실펀해볼 수 있는 범위
• 고객은 프론트엔드 개발자 혹은 API 활용하는 사람 대상
• API 접점에서 검증하는 E2E 테스트
• API의 Request와 Response 정보 이외 내부 정보는 최대한 가리는 블랙 박스 형식의 테스트

인수 테스트 만들기

블랙 박스 테스트

• 인수 테스트는 블랙 박스 테스트의 성격을 가지고 있음

블랙박스?

• 클라이언트는 결과물의 내부 구현이나 사용된 기술을 기반으로 검증하기 보다는 표면적으로 확인할 수 있는 요소를 바탕으로 검증하려 함
• 실제 사용하는 상황의 시나리오를 바탕으로 요구사항을 작성
• 내부 구현이나 기술에 의존적이지 않는 블랙 박스 테스트

E2E 테스트

• API 레벨의 블랙박스 테스트 이므로 요청과 응답 기준으로 API 레벨의 E2E 테스트로 검증

SpringBoot Test

• 테스트에 사용할 ApplicationContext를 쉽게 지정하게 도와줌
• 기존 @ContextConfiguration의 발전된 기능
• SpringApplication에서 사용하는 ApplicationContext를 생성해서 작동

RestAssured

• mockmvc를 안쓰는건 이유가 있음
• REST-assured는 REST API의 테스트 및 검증을 단순화하도록 설계
• HTTP 작업에 대한 검증을 위한

JsonPath

 

인수 테스트 실습

- 지하철역 생성 인수 테스트 만들기

MockMvc vs WebTestClient vs RestAssured

- MockMvc : mocking 된 web environment (ex tomcat) 환경에서 테스트

- WebTestClient : Netty를 기본으로 사용

- RestAssured : 실제 web environment(Apache Tomcat)을 사용하여 테스트

+) DirtiesContext를 써야 테스트 코드의 격리가 되나, 테스트 비용이 커진다 (컨테이너를 다시 띄움)
+) Random Port를 쓰면 Transactional 과 rollback 이 안됨
+) DB를 초기화 하는 방법을 미션에서 찾아보기

ATDD Cycle

인수 테스트 주도로 개발은 어떻게 하나요?

• 인수 조건 정의
  - 인수 테스트가 충족해야하는 조건
  - 이번 과정에서는 시나리오 형태로 표현
• 인수 조건 형식
  - scenario-oriented
  - rule-oriented
  - custom formats
• 인수 테스트
  - 인수 조건을 검증하는 테스트
  - 실제 요청/응답하는 환경과 유사하게 테스트 환경에서 구성