[인프런 워밍업 스터디 클럽 2기 백엔드] 4주차 + 회고
해당 글은 인프런 박우빈 강사님의 「Practical Testing: 실용적인 테스트 가이드」을 바탕으로 작성하였습니다.
강의 요약
Presentation Layer
외부 세계의 요청을 가장 먼저 받는 계층
사용자 입력 값, 프론트엔드에서 주는 값, 요청 등...
주요 로직은 없지만, 최소한의 유효성 검증을 수행한다.
레이어드 아키텍쳐의 단점
도메인에 강하게 의존
도메인에 레포지토리를 위한 어노테이션을 필연적으로 붙여야 하는 문제 발생
⇒ 대안: 헥사고날 아키텍쳐
Mockito로 stubbing 하기
가짜 객체를 만들어 행위를 지정하고 테스트하는 방법 (자세한 내용은 미션 6 참조)
Test Double
dummy: 아무것도 하지 않는 깡통 객체
fake: 단순 형태로, 동일 기능을 수행. 프로덕션에서 쓰기에는 부족한 객체
stub: 테스트에서 요청한 것에 대해 기록하여 보여줄 수 있는 객체. 정의하지 않은 요청에는 무응답
spy: stub이면서, 호출된 내용을 기록하여 보여줄 수 있는 객체. 일부는 실제 객체처럼 동작.
mock: 행위에 대한 기대를 명세하고, 그에 따라 동작하도록 만들어진 객체
stub vs mock
stub은 상태를 검증
mock은 행위를 검증
더 나은 테스트 작성하기
한 문단에는 한 가지 주제만!
'테스트 코드 = 문서' 라는 것을 항상 인지해야 한다.
완벽한 제어
시간, 랜덤 등은 외부에서 주입받도록 리팩토링 하기. 강의 예제의 가게의 영업시간을 테스트했던 것을 기억하자.
외부 세계와 소통해야 하는 것은 mocking을 이용한다.
독립성 보장하기
한 테스트 메서드에는 한 가지 기능만 테스트하기
given에서는 가급적 순수 생성자 또는 빌더를 통해 생성하기
검증이 있는 팩토리 메서드는 사용 시 예외 발생 가능성이 있다.
테스트는 순서 보장이 안 되어 있다.
Fixture 구성
@BeforeEach, @BeforeAll
중복 코드를 줄일 수 있지만 테스트 간의 결합이 생겨버린다.
신중한 사용이 필요!
Fixture 클렌징
deleteAll vs deleteAllInBatch
deleteAllInBatch(): 중간 테이블에 외래키 등으로 인한 오류 발생 때문에 데이터 삭제 순서를 고려해야 함. → 코치님의 추천 메서드
deleteAll(): 순서 고려 필요가 없고 연관 테이블을 자동적으로 같이 지워주지만, 삭제 쿼리가 복잡하게 나간다! 전체 테이블을 조회하고 건별로 삭제하는 방식이기에 불필요한 쿼리가 늘어난다.
@ParameterizedTest
케이스 확장할 때 좋은 방식!
재고 타입 테스트할 때를 기억하기!
@CsvSource로 제공된 데이터를 @ParameterizedTest가 붙은 메서드의 파라미터에 각각 제공 가능
@CsvSource 외에도 @MethodSource, @ValueSource 등이 존재
@DynamicTest
일련의 시나리오를 테스트
@TestFactory가 붙은 메서드에서 Iterable한 반환 값을 던지는 형태
공통의 환경에서부터 일련의 사건을 실행시켜 테스트가 가능.
given/when/then 세트가 복수로 생기기 때문에 가독성 저하에 주의하기.
환경 통합하기
gradle 탭의 tesk에서 test를 수행하면 전체 테스트를 수행해보기
전체 테스트 시 Spring Boot가 여러번 로딩하게 되면 비용과 시간 증가...!
서버가 발생하는 횟수를 줄여야 한다!
서버를 띄우는 @SpringBootTest과 profile을 지정하는 @ActiveProfile을 별도의 상위 클래스에 붙여 Test 클래스들에 상속시키기!
mock도 별도의 환경으로 취급하기 때문에 mock 객체는 상위 클래스에서 protected로 생성하거나 mock이 필요한 환경을 별도로 설정하기.
환경 통합을 위해, @DataJpaTest보단 @SpringBootTest를 사용하기
private 메서드를 테스트하기
결론적으로는, 할 필요도 없고 하려고 해서도 안된다!
그래도 고민된다면, 객체를 분리할 시점인지 관해 생하기
분리가 필요하다고 판단된다면 객체를 별도로 분리해 private 메서드를 공개 메서드로 작성하면 된다.
private 메서드는 외부에서 공개하고 싶지 않은 것이고 외부에서는 몰라도 되는 부분이다! public 메서드를 검증하다보면 자연스레 검증되는 부분이다!
+ α
헥사고날 아키텍쳐
도메인 주도의 아키텍쳐
QueryDSL
JPA 사용 시 거의 필수
타입 체크, 동적 쿼리(값에 null이 들어올 시 자동으로 동적으로 조회해줌)가 가능
낙관적 락, 비관적 락
CQRS(Command and Query Responsibility Segregation)
DB에서 조회와 업데이트를 분리
미션
미션 5, 6은 직접 테스트 코드를 작성했던 네 번째 미션 보다는 훨씬 편안한 내용이었다. 강의 내에서 이미 정답을 다 알려준 느낌이고, 내 나름의 언어로 정리해보는 느낌이었다.
쉽다고 만만히 보았기 때문일까... 특강 때 공통 피드백을 받고 바로 아차 싶었다. @BeforeEach 부분은 단순 중복 제거를 위한 것이 아니라는 점을 간과했다. 리팩토링 강의에서부터 가장 강조하신 것 중 하나가 도메인인데 그것을 놓치다니...🤣🤣 정답은 맞췄어도 풀이 과정 때문에 반타작 밖에 못한 기분이었다.
후기
벌써 4주차, 마지막 발자국이자 워밍업 클럽 2기의 마무리이다. 한 달이라는 시간이 쏜살같이 지나가버렸다. 테스트 코드와 리팩토링에 대해 심도 있게 다가간 것은 처음이었던 나에게는 정말 어려웠다. 강의에서 들었던 내용을 과제에 적용하는 과정은 험난했다. 과제를 모두 제출하고 완주를 한 것 만으로도 만족해버리고 말았다.
당장 다음주 시작부터, 새로운 스터디가 시작된다. 같이 워밍업 클럽에 참여하신 분의 자바 스터디인데, 기초부터 다시 다잡는다는 느낌이라 굉장히 기대가 된다. 👏👏
마지막으로, 이런 자리를 마련해주신 인프런과 코치님, 그리고 내 부족한 미션 피드백을 해주신 다른 스터디 참여자 분께 감사의 말씀을 드리고 싶다. 언젠가 3기가 열린다면, 다시 한 번 도전하고 싶다!
답변 0