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. 코드 작성시 캡슐화, 인터페이스화 고려
JgraphPathFinder 라는 인터페이스가 Line 하위에 있는 Sections라는 일급컬렉션을 사용함
List<Section> 으로 변경해서 사용하는것을 고려해야함
Lombok으로 Line의 Sections에 getter를 붙이게 되고 해당 부분은 은닉 되지 못함
해당 부분은 필수적으로 public 처리가 안되도 가능했던 부분임 (1번의 영향으로 getter 사용)
B. 기본 사항들
미사용 import 정리 안함
포맷 사항 확인하지 않음
HTTP 코드 잘못알고 사용 409 와 400
오류 메시지를 검증 할때, ENUM을 사용하게 되면 테스트 편해짐
C. 인수테스트 기본사항들
시나리오 의도가 드러나는 인수테스트는 주석에서 5같은 상수를 사용하지 않는다.
테스트 작성하고 싶은 PRIVATE 메서드가 있다면 설계 확인 필요하다
테스트만을 위한 프로덕션 코드는 지양
생성자, stubbing, reflection은 제한적 허용
D. 서비스 -> 서비스 의존 VS 서비스 -> REPOSITORY 의존
비대한 서비스는 READ 로 분리
한단계 높은 서비스를 의존 받는 서비스를 생성
E. 도메인과 서비스의 분리
도메인 로직으로 비즈니스 로직을 내리면 수정사항이 생길 때,
아름답게 도메인 로직만 고치는 경험을 할 수 있었습니다!
3. 구현 사항
1단계 - 지하철 구간 추가 기능 개선
구간 추가 제약사항 변경(예외 케이스 포함)
2단계 - 지하철 구간 제거 기능 개선
구간 삭제에 대한 제약 사항 변경 구현
기존에는 마지막 역 삭제만 가능했는데 위치에 상관 없이 삭제가 가능하도록 수정
3단계 - 경로 조회 기능
외부 라이브러리(JGraph)를 이용하여 두 역사이의 경로 조회를 구현한다.(예외 포함)
설계에 어려움을 겪었던 부분:
역 리스트 조회 부분에서 순서에 맞게 역 리스트 조회하는 부분
index 집어 넣었다가 -> 다시 index 없이 구현
중간 구간에 구간을 추가하면서 생기는 순서 문제 부분
index 제거후에 하행역 매칭방식으로 구현
느낀 점
Last updated