[Review] ATDD 4주차 1차 PR

 

최홍준 리뷰어 님께 감사의 말을 전하고 싶다!!

 

1. 질문

1-1) 인수테스트 작성과 문서 작성

우선 ATDD 사이클에 의하여

1. 인수테스트 작성
2. RestDocs 작성
   순서로 진행하게 되었습니다.

다만 인수테스트를 작성했을때 최단 시간으로 경로를 찾는 인수테스트가 통과를 하지는 못하는 상황 이였습니다.

@DisplayName("두 역의 최단 시간 경로를 조회한다.")
@Test
void findPathByTime() {
    // when
    ExtractableResponse<Response> response = 두_역의_최단_시간_경로_조회를_요청(교대역, 양재역);

    // then
    assertThat(response.jsonPath().getList("stations.id", Long.class)).containsExactly(교대역, 강남역, 양재역);
}

최단 거리 경로 : 교대역 -> 남부터미널역 -> 양재역
최단 시간 경로 : 교대역 -> 강남역 -> 양재역

 

즉, 구현이 최단 거리 기준으로 구현되어 있어서 시간 기준으로 인수테스트를 작성해도 구현 수정 없이는 해당 인수테스트가 통과할 수 없었습니다.

 

따라서 실패하는 테스트로 둔 후, 문서를 작성하여 build를 하니 직전의 인수테스트 실패로 인하여 문서가 build되지 않았습니다.
snippets 생성이 되지 않았습니다.

 

어쩔수 없이 구현을 해버린 후 문서를 작성하게 되어버렸습니다...

말이 길어졌는데... 어떻게 해결했어야 할까요?

 

최홍준 리뷰어 답변:

음?? 약간 나의 의도를 명확하게 전달하지 못한것 같다 ㅠ.ㅠ

 

이번에는 마스터인 성현님의 답변이다:

아예 새로운 API를 만들고 문서화 하는 방향이 의도하신 방향이라 알려주셨다!

다음번 부터는 새로운 API를 만들고 시작해봐야 겠다!

 

2. 리뷰 정리

2-1) 전략 패턴의 활용

이번 구현에서 잘했다고 생각되는 점 이다!

 

최단 거리를 찾아야 하는데, 그 기준이 거리인지? 시간인지? 에 따라서 경로가 달라진다.

따라서 지도를 초기화 시켜주는 로직 자체를 인터페이스로 분리하였다.

public interface EdgeInitiator {
    void initEdges(List<Line> lines, SimpleDirectedWeightedGraph<Station, SectionEdge> graph);
    void initOppositeEdges(List<Line> lines, SimpleDirectedWeightedGraph<Station, SectionEdge> graph);
}

 

이후 이를 구현하는 전략을 2개, DistanceEdgeInitiator, DurationEdgeInitiator 를 구현하였다.

이후 아래 사진과 같이 필요한 시점에 findPath의 인자로 넘겨 초기화 하여 사용하도록 하였다!

 

 

2-2) 인수 테스트 인가? 단위 테스트 인가?

 

나의 답변:

 

우선 좋은 리뷰 감사합니다!

다만 역방향에 대한 검증은 단위 테스트에서 구현되어야 할것 같다 생각합니다.
인수테스트 상에서 역방향 시나리오가 따로 없는 상황에서 역방향 검증은 단위 테스트에서 해야하지 않을까? 란 생각이 듭니다.

SubwayMapTest에 구현해보도록 하겠습니다.

이에 대한 리뷰어님의 의견이 궁금합니다!

 

리뷰어 답변:

넵! 좋습니다.
말씀하신 것처럼 인수테스트, 서비스 테스트, 도메인 테스트에서 중요도와 요구사항에 맞게 작성해 주시면 된다고 생각합니다 :)
다만 개인적인 생각으로는 도메인에서의 테스트는 최대한 꼼꼼하게 진행되야 한다고 생각하고 있습니다 😃
미션을 진행하면서 학습을 하는 만큼 여유가 되신다면 인수 테스트도 작성해 보는 것도 도움이 되실 것 같아요 👍

 

2-3) 장황한 문서 코드

 

나의 답변:

음 해당 코드 같은 겨우 문서에 가까운데, 이걸 꼭 분리해야하나? 란 생각이 듭니다.

적절한 이름의 메서드로 분리하면 코드의 길이는 줄겠지만, 어짜피 해당 메서드를 통해 본문 부분을 읽으러 또 이동해야하지 않나?
란 생각이 듭니다 ㅎㅎ

재활용을 하기도 힘들다 생각되는 점이, API마다 필요한 값, 반환값이 다 다르기 때문에 메서드로 뽑아도 재사용을 힘들것 같다 생각하였습니다.

 

이에 대한 의견이 궁금합니다!

 

리뷰어 답변:

저는 문서화 코드도 충분히 재사용 가능하다고 생각합니다.
물론 작은 단위의 application에서는 api의 스펙이 변화 해도 영향도가 적지만
규모가 커 질수록 api의 버전관리와 함께 스펙이 재사용 되는경우도 많다고 생각해요.

현재 상황에서 문서 수정을 할 경우에도 분리가 되어 있다면 조금더 빠르게 파악하고 수정 가능하지 않을까요?

 

리뷰어님의 의견을 수용하여 일단 중복 부분을 추출하였다.

막상 추출하고 보니 추출한 함수로 중복사용이 가능했다. ㅎㅎ

적용해보기 전에는 보이지 않았던 부분이 보여서 좋았다!!