이전 내용: 클린코드
[인프런 워밍업 클럽 백엔드 스터디 2기] 1주차 발자국
[인프런 워밍업 클럽 백엔드 스터디 2기] 2주차 발자국
테스트 코드
[인프런 워밍업 클럽 백엔드 스터디 2기] 3주차 발자국
Mock을 마주하는 자세
Test Double, Stubbing
- Dummy : 아무 것도 하지 않은 깡통 객체
- Fake : 단순한 형태로 동일한 기능은 수행하나, 프로덕션에서 쓰기에는 부족한 객체
- Stub : 테스트에서 요청한 것에 대해 미리 준비한 결과를 제공하는 객체
- Spy : Stub이면서 호출된 내용을 기록하여 보여줄 수 있는 객체입니다. 일부는 실제 객체처럼 동작시키고 일부만 Stubbing할 수 있습니다.
- mock : 행위에 대한 기대를 명세하고, 그에 따라 동작하도록 만들어진 객체
Stub : 상태 검증
Mock : 행위 검증
@Mock, @MockBean, @Spy, @SpyBean @InjectMocks[설명링크]
더 나은 테스트를 작성하기 위한 구체적 조언
- 한 문단에 한 주제!
- 완벽하게 제어하기
- 객체 내부에서 랜덤값을 테스트 코드로 비교할 수 없다면 DI를 통해서 외부에서 주입받아 테스트 코드를 작성합니다.
- 테스트 환경의 독립성을 보장하기
- 순수한 생성자로만 테스트 기본절을 구성하는 것이 더 좋습니다. (.SQL 파일로 데이터를 인입받는 것은 지양합니다)
- 두 가지 이상의 테스트가 하나의 자원을 공유합니다. 공유 자원을 사용하지 말고 독립적으로 사용합니다.
- Test Fixture 클렌징
- DeleteAllInBatch를 사용하는 것을 추천합니다 (DeleteAll은 많은 쿼리가 실행됨).
- 기본적으로 클래스 위에 @Transactional을 사용하지만, 배치 같은 트랜잭션이 혼용되는 곳에서는 DeleteAllInBatch를 많이 사용합니다.
- DeleteAllInBatch를 사용하는 것을 추천합니다 (DeleteAll은 많은 쿼리가 실행됨).
- 테스트 수행도 비용입니다. 환경 통합하기❗❗
- IntegrationTestSupport 추상 클래스를 상속받아 테스트 코드를 만듭니다.
- 이를 통해 Spring Boot를 띄우는 횟수를 줄이고 최적화를 진행할 수 있습니다.
- IntegrationTestSupport 추상 클래스를 상속받아 테스트 코드를 만듭니다.
@ActiveProfiles("test")
@SpringBootTest
public abstract class IntegrationTestSupport {
}
@WebMvcTest(controller = {
OrderController.class,
ProductController.class
})
public abstract class ControllerTestSuport {
}
테스트를 작성하는 마음가짐
테스트를 왜 해야 되는가? 테스트 코드는 귀찮은 작업입니다. 하지만 왜 해야 되는지 마음속에 명확히 인지하고 있어야 귀찮음을 이기고 테스트를 작성할 수 있습니다.
최적의 상황을 판별하고 맞게 도구를 빠르게 사용을 할 수 있어야 진짜 프로입니다. 지속적으로 도구를 사용하는 방법을 연습하고, 타협하지 않는 마음으로 테스트를 작성해 나가면 미래의 수많은 시간을 아낄 수 있습니다.
4주차 회고
클린코드와 테스트코드 학습의 마지막 날입니다.
올해 1월부터 시작한 프로젝트의 오픈 날짜가 10월 28일과 겹치면서 야근도 많았지만, 끝까지 완주해낸 제 자신이 뿌듯합니다. 클린코드와 테스트코드는 실무에서 정말 필수적인 요소라고 생각합니다. 이번 기회에 배운 것들을 혼자만 실천하는 것이 아니라, 동료들과 공유하고 함께 좋은 코딩 습관을 만들어가도록 하겠습니다.
2024년이 얼마 남지 않았지만, 올해 가장 잘한 일 중 하나라고 자부하고 앞으로도 이러한 원칙들을 항상 인지하면서 코드를 작성하도록 하겠습니다.
감사합니다.
댓글
GitHub 계정으로 로그인하시면 댓글과 질문을 남기실 수 있습니다. 남겨 주신 글은 이 저장소의 Discussions에 쌓입니다.