2주차 인수테스트와 TDD

0. [이론] 배운 사항들

  • 인수테스트 리팩토링

    • 테스트의 의도를 명확히 드러내기

      • 시나리오 흐름에 맞게끔

      • 메서드 분리 필요

    • 가독성이 좋지 않으면 방치된다.

    • 테스트 코드 중복 제거

      • 스텝 메서드 STATIC 선언 및 별도의 클래스 분리

      • CRUD 추상화

      • Cucumber 사용

  • 단위테스트

    • 협력 객체에 따른 구분

      • 통합 - 협력객체 실제 사용

      • 고립 - Mock 객체 사용

        • @MockBean 사용

    • Test Double

      • 실제 객체 대신 사용되는 모든 종류의 객체를 명시

      • Dummy Object

      • Test Spy

        • 객체의 특정행위 지정

      • Test Stub

        • 테스트 대상의 상태 설정

        • @MockBean 사용

        • 미리 약속한 결과를 응답하도록 하여 상태 검증

      • Fake Obj

        • 실제 객체가 있지만 fake obj가 호출 가로챔

      • Mock Obj

        • 동작을 검증 하는 방식

        • 호출 횟수, 인자

  • 추천 방향

    • 인수 테스트 이해

    • 설계 흐름 구상

    • 도메인부터 ~ 컨트롤

1. [실습] 구현 단계들

1단계 - 지하철 구간 추가 기능 개선

2단계 - 지하철 구간 제거 기능 개선

3단계 - 경로 조회 기능

존재하는 기능으로부터

  • 복잡한 수정 요구사항이 생길때,

    • 인수조건들을 도출

    • 인수테스트를 수정하는 방법을 숙지

    • 리팩토링을 진행

2. [실습] 배운 사항

A. 코드 작성시 캡슐화, 인터페이스화 고려

  1. JgraphPathFinder 라는 인터페이스가 Line 하위에 있는 Sections라는 일급컬렉션을 사용함

    1. List<Section> 으로 변경해서 사용하는것을 고려해야함

  2. Lombok으로 Line의 Sections에 getter를 붙이게 되고 해당 부분은 은닉 되지 못함

    1. 해당 부분은 필수적으로 public 처리가 안되도 가능했던 부분임 (1번의 영향으로 getter 사용)

B. 기본 사항들

  1. 미사용 import 정리 안함

  2. 포맷 사항 확인하지 않음

  3. HTTP 코드 잘못알고 사용 409 와 400

  4. 오류 메시지를 검증 할때, ENUM을 사용하게 되면 테스트 편해짐

C. 인수테스트 기본사항들

  1. 시나리오 의도가 드러나는 인수테스트는 주석에서 5같은 상수를 사용하지 않는다.

  2. 테스트 작성하고 싶은 PRIVATE 메서드가 있다면 설계 확인 필요하다

  3. 테스트만을 위한 프로덕션 코드는 지양

  4. 생성자, stubbing, reflection은 제한적 허용

D. 서비스 -> 서비스 의존 VS 서비스 -> REPOSITORY 의존

  1. https://github.com/next-step/atdd-subway-map/discussions/489

    1. 비대한 서비스는 READ 로 분리

    2. 한단계 높은 서비스를 의존 받는 서비스를 생성

E. 도메인과 서비스의 분리

도메인 로직으로 비즈니스 로직을 내리면 수정사항이 생길 때,

  1. 아름답게 도메인 로직만 고치는 경험을 할 수 있었습니다!

3. 구현 사항

  • 설계에 어려움을 겪었던 부분:

    • 역 리스트 조회 부분에서 순서에 맞게 역 리스트 조회하는 부분

      • index 집어 넣었다가 -> 다시 index 없이 구현

    • 중간 구간에 구간을 추가하면서 생기는 순서 문제 부분

      • index 제거후에 하행역 매칭방식으로 구현

느낀 점

Last updated