[ATDD] 3. ATDD 기반 리팩터링

목차

1. 인수 테스트 통합

2. 레거시 리팩터링

 

 

 

전체 코드 확인

 

1. 인수 테스트 통합

1) 인수 테스트 리팩터링

인수 테스트를 다음 세가지 방법으로 리팩터링 하면서 활용해 볼 수 있다.

• 인수 테스트 리팩터링 : 메소드 분리, 스텝 분리 참고
• 단위 테스트로 분리 : 비지니스 규칙에 대한 부분을 단위 테스트로 분리
• 인수 테스트 통합 : CRUD 각각의 인수 테스트를 하나로 통합

 

2) 인수 테스트의 검증 범위

인수 테스트에서 요청에 대한 검증을 어느정도 까지 해야할지에 대한 고민.

응답 코드로 확인하는 방법

요청을 한번 더 보내서 응답값을 확인하는 방법

given/when/then 이후 추가 스탭이 필요함

테스트 목적은 다르지만 같은 로직을 검증하는 인수 테스트가 발생할 수 있음

(생성에 대한 인수 테스트에서 조회에 대한 검증이 포함되기 때문에 조회에 대한 인수 테스트와 함께 조회 중복 검증이 발생한다.)

 

3) 인수 테스트 통합

생성, 조회 등 CRUD에 대한 각각의 인수 테스트를 하나로 통합하는 방식으로 리팩터링을 진행한다.

인수 테스트 검증 범위에 대한 고민을 어느정도 줄여줄 수 있다.

 

인수 테스트 통합 예시

 

단점

하나의 테스트가 많은 것을 검증하게 된다.

테스트를 작성하기 어려워진다.

 

장점

api 단위가 아닌 사용자 관점의 기능과 플로우를 검증 대상으로 설정할 수 있다. (Journy Test or Story Test)

테스트 비용을 절감할 수 있다.

스텝의 중복을 효과적으로 제거할 수 있다.사이드 케이스는 단위 테스트에서 수행하게 유도할 수 있다.

 

방법

(1) 기존 처럼 따로 만든 다음 하나로 통합하기

(2) 처음부터 하나의 테스트 메서드로 한 스텝씩 검증하면서 구현하기

 

 

2. 레거시 리팩터링(인수 테스트를 이용한)

1) 인수 테스트가 있는 경우

인수 테스트가 있으면 레거시를 리팩터링 할 때 인수테스트가 성공하는 시점으로 돌아갈 수 있기 때문에

기능 변경 혹은 리팩터링을 하더라도 마음껏 할 수 있다.

 

2) 인수 테스트가 없는 경우

스트랭글러패턴 참고 

인수 테스트를 먼저 만들고 시작세부 구현에 의존하지 않는 블랙박스 테스트이기 때문에 기능이 변경되어도 테스트가 가능하다.

 

인수 테스트 다음 스텝

• 인수 테스트를 성공시키기 위한 단위 테스트 작성
• 단위 테스트를 성공시기기 위한 기능 구현 (or 리팩터링)
• 단위 테스트 성공 후 리팩터링
• 그리고 반복

 

레거시 리팩터링 단계

기존의 프로덕션 코드를 바로 수정하면 변경한 부분을 의존하는 부분에서 문제가 발생

기존의 테스트 코드를 바로 수정하면 기존의 프로덕션 코드를 검증할 수 없게됨

• 새로운 테스트 만들기(ATDD + TDD)
• 기능 구현하기
• 기존 테스트, 프로덕션 코드 제거

 

기능 구현하기 단계

기존 코드와 신규 코드가 함께 존재함

기존 코드가 유지되기 때문에 이슈가 발생하지 않음

기존 코드와 신규 코드가 혼재되는 기간을 짧게 가져가도록 해야함

 

 

 

 

 

 

 

 

출처

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