[ATDD, 클린 코드 with Spring 6기] 4주차 정리

1. 개요

1) 테스트 하기 쉬운 코드로 만들기 (영상)

테스트하기 쉬운 코드란?

1. 같은 입력에 항상 같은 결과를 반환하는 코드
2. 외부 상태를 변경하지 않는 코드

테스트하기 쉬운 코드로 만들기

• STEP1) 테스트하기 쉬운 코드와 어려운 코드를 분리한다
• STEP2) 두 분류의 코드를 최대한 바깥쪽에서 만나게 한다
  • 테스트의 어려움은 안에서 밖으로 전파된다
  • 따라서 테스트하기 쉬운 코드와 어려운 코드를 최대한 바깥쪽에서 만나게 해야 한다
• STEP3) 두 분류의 코드가 만나는 지점을 자동 테스트로 검증한다

 

2) 인수 테스트 리팩터링

기존 인수 테스트의 문제점

• 테스트의 목적이 다름에도 불구하고 같은 로직을 검증하는 인수 테스트가 생기게 됨
  • 즉, 중복이 발생함

 

인수 테스트 통합

• 각 기능 단위로 분산되어 있던 인수 테스트들을 흐름 단위로 통합할 수 있음

• 이는 다음과 같은 장점을 지닌다
  • 테스트 비용 절감
  • 인수 테스트 스텝(Step)의 중복 제거
  • 흐름 검증 및 사용자 스토리에 대한 검증 병행
  • 엣지 케이스는 단위 테스트에서 수행하게 유도

 

인수 테스트 통합 방법

1. 개별 기능 단위로 따로 만든 후 하나로 통합
2. 처음부터 하나의 큰 흐름 단위로 만드는 방법

 

3) 레거시 리팩터링

레거시 리팩토링 하기

• 레거시는 인수 테스트가 있는 상황과 인수 테스트가 없는 상황으로 나뉘며, 통상적으로 전자일 확률이 높다
• 인수 테스트가 있는 경우 
  • 해당 인수 테스트를 기반으로 리팩토링을 수행하면 된다
• 인수 테스트가 없는 경우
  • 인수 테스트를 먼저 만들고 리팩토링을 시작해야 한다
  • 세부 구현에 의존하지 않는 블랙박스 테스트이므로 구현이 변경되더라도 검증할 수 있다

 

리팩토링 과정

• 사전 주의사항
  • 기존 테스트 코드를 바로 건드리면 안 된다
  • 최소한의 방어막이 사라지는 셈이다
• STEP1) 새로운 테스트 만들기
  • 반드시 기존 테스트와 프로덕션 코드는 남겨야 한다
• STEP2) 기능 구현하기
  • 기존 코드와 신규 코드가 함께 존재하게 됨
    • 기존 코드가 유지되어 기능에 문제가 없고, 신규 작업한 코드도 그대로 남아있는 상태
    • 기존 코드와 중복이 발생할 수 있는 단계
  • 단, 기존 코드와 신규 코드가 혼재되는 기간은 짧아야 함
• STEP3) 테스트 성공 후 리팩토링
  • 이때, 리팩토링은 테스트 코드가 검증할 수 있는 범위 내에서 시도해야 한다
• STEP4) STEP1 ~ STEP3을 반복한다
  • 기존 코드를 대체할 수 있을 때 대체한다
    • 대체가 가능할 때 기존 프로덕션 코드와 테스트 코드를 제거한다

 

4) 문서화 자동화

문서 자동화란?

• 문서를 기능과 동기화하기 어려우므로 이를 코드에서 관리하여 해결하는 방법
• 이를 지원하는 도구엔 대표적으로 Swagger와 Spring Rest Docs가 있다

 

Swagger

• API를 호출하여 테스트하는 기능에 특화된 도구
• 기능이 많다는 장점이 있지만 사용 시 불필요한 프로덕션 코드 오염이 발생한다

 

Spring Rest Docs

• API를 호출하는 도구가 아닌 단순히 문서를 만들어주는 도구
• 테스트 코드에 설정/작성하여 프로덕션 코드에 영향을 적게 미친다
• API를 호출하는 기능은 로컬에서 Http Request를 함으로써 대체한다
• Test → Snippets → Template → Document의 흐름을 지님
  • Test: 테스트 수행
  • Snippets: 작은 문서 조각
  • Template: 문서 조각을 담는 틀
  • Document: 실제로 산출되는 문서

 

 

2. 4주차 리뷰

1) PR

• https://github.com/next-step/atdd-subway-fare/pull/268
• https://github.com/next-step/atdd-subway-fare/pull/285
• https://github.com/next-step/atdd-subway-fare/pull/303

 

2) 리뷰 정리

• Sprint Rest Docs 사용 시 요청/응답에 설명을 추가하자
• @ParameterizedTest의 name 속성을 활용하면 가독성이 좋은 테스트를 작성할 수 있다
• 사용자 정의 Exception을 사용하여 클라이언트에게 정확한 예외 이유를 전달하자

 

 

3. 느낀 점

Spring Rest Docs는 이야기만 들어보고 처음 접해봤는데 신세계였다. 회사에선 Swagger + Wiki를 이용하고 있는데, 이렇게 하다보니 문제점이 있었다. 첫 번째는 문서화를 위해 프로덕션 코드를 수정하는 일이 빈번하다는 점이고, 두 번째는 코드를 수정하고나서 동기화를 위해 Wiki를 수정해야 하는데 이게 상당히 번거롭다는 점이었다.

 

반면, Spring Rest Docs는 테스트 코드만 수정해서 동기화에 대한 걱정없이 쉽게 문서화를 할 수 있는 점이 좋았다. 개인적으론 Spring Rest Docs의 초기 설정이 좀 더 어려운 느낌이었는데, 익숙해지면 유용하게 쓸 수 있을 것 같다. 물론 스웨거는 직접 API call을 해볼 수 있

다는 점이 너무나도 막강하긴 한데... 다음에 새로운 프로젝트를 세팅하게 되면 적용하는 것도 고려해봐야겠다.

 

이번 주차를 마지막으로 ATDD 강의가 모두 끝났다. 뿌듯하기도 했고... 미션을 수행하면서 디테일한 부분에서 놓친 게 많았다는 점과 개인 일정으로 인해 추가 미션을 못해서 아쉽기도 했다. 아쉬움을 뒤로한 채 미션 리뷰는 이것으로 마친다!