[우아한테크캠프 pro 2기] 5주차 미션 인수 테스트 기반 TDD 후기, 코드리뷰

5주 차 미션 : 인수 테스트 기반 TDD (지하철 노선 관리)

 

저장소 : https://github.com/next-step/atdd-subway-service/tree/prodo-developer

 

느낀점

• 인수 테스트의 각 스텝들을 메서드로 분리
• 불분명한 익셉션 처리는 기능에 맞는 익셉션으로 분리
• 시나리오 인수 테스트 작성, 도메인 단위 테스트 작성

이번 과정의 목표 경험

• 객체들간의 역할과 책임 분리
• 인수 테스트 기반의 TDD 경험
• @ControllerAdvice를 이용한 Exception handler
• 인증과 인증 도구 학습

내 코드 피드백

"동일한 테스트 세트에서 테스트 대상이 되는 메서드를 테스트 조건으로 사용하지 않음"

 

조건으로 사용한 메서드가 가지는 요구사항 테스트가 실패할 때 해당 테스트도 반드시 실패하게 되므로 무엇이 실패하는지 명확히 알 수 없습니다.

 

테스트를 작성하는 방법을 통해 기존에 @BeforeEach와 전역변수로 선언했던 것들을 테스트의 조건은

각 테스트에 배치함으로써 "중복코드를 제거하는 것이 필요하다면 메서드로 추출하여 각 테스트의 맥락에서 해소할 수 있었습니다".

이집트 괄호라는것을 이번 캠프를 통해 처음 알았다. 생각 없이 인스턴스를 만들다 보면 항상 위에 시작 괄호가 있고 아래에 닫는 괄호를 사용하기도 했었고, 단순하게 리턴만 하는경우라면 괄호를 사용하지 않았다.

이럴 때 사용하는 것이 "Egyptian brackets" 좋은 방법이었다.

 

참조 비교로 동등을 확인하기에는 불안한 요소가 많았기 때문에 '=='에서 'equals'로 변경 하였다.

 

코드스멜(.get(0)) 방지하기 위해 익셉션 처리를 통해 방어 코드를 작성 하였다. 

 

기존에는 PathFinder에 경로를 찾기 위한 다익스트라 알고리즘을 포함 기능들이 모두 밀집되어 있어,

PathFinder와 JgraphtFinder는 강한 결합을 가지고있어, 인터페이스(PathFinder)와 구현체(JgraphtFinder)로 역할별로

나눔으로써 결합도를 낮출 수 있었다.

 

AuthenticationPrincipal의 경우 url 접근시 인가/인증의 관련한 기능을 명시하기 때문에 비지니스까지 작성하는건

올바르지 않다. 따라서 Controller에 적는것을 권장한다. 주의하자.

 

후기

인수테스트 미션부터 그 동안 해왔던 TDD, ATDD가 모두 들어가져 있었으며 낯설었던 테스트들을 기존 미션보다 좀 더 수월하게 진행할 수 있었다.

 

하지만 여전히 요구사항들, 객체 설계, 테스트 코드 작성, 도메인 분리 등 쉽지만은 않은 과정이다.

 

킹뽀대님의 디테일한 피드백에 다시 한번 감사드리며, 다음 미션이 들어와도 지금 보다 점진적인 좋은 코드를 만들 수

있다는 자신감이 생겼다.