워밍업 클럽 3기 BE 클린코드&테스트 - 4주차 발자국
Layered Architecture 구조의 레이어별 테스트 정리
Persistence Layer
특징: 데이터를 직접 접근하고 관리하는 계층.
테스트 방법: CRUD 중심으로 테스트하되, 비즈니스 로직은 포함하지 않는다.
유의점: 테스트 수행 후 데이터 정리(clean-up)를 철저히 해야 한다.
Business Layer
특징: 비즈니스 로직이 전개되는 중심 계층.
테스트 방법: 통합 테스트로 비즈니스 로직의 정확성을 검증하며, 예외 상황 처리에 더 많은 집중이 필요하다.
유의점: 예외 케이스를 잘 다루는 것이 개발자의 역량이다.
Presentation Layer
특징: 외부 요청을 처리하는 계층.
테스트 방법: 입력 값의 유효성을 검증하며, 하위 레이어는 모킹 처리하여 독립적으로 테스트한다.
유의점: 유효성 검증이 어느 레이어에서 이루어져야 하는지 신중하게 고민해야 한다.
Mocking에 대한 이해와 활용
Mock 객체를 활용하는 것이 단위 테스트의 핵심이라고 할 수 있다.
Mock 객체는 실제 객체의 행위를 대신할 수 있는 가짜 객체로, Mockito 같은 라이브러리를 활용해 쉽게 만들 수 있다.
중요한 것은 Mock 객체를 사용할 때, 실제 객체의 동작을 완벽하게 대체한다고 생각하지 말고 의심하고 검증하는 태도를 유지하는 것.
특히, Mock 객체의 역할과 Stub의 역할을 동시에 수행할 수 있다는 점을 배웠다.
또한, Mocking이 들어가는 순간 그것은 단위 테스트라는 개념을 다시 한번 되새길 수 있었습니다.
@Mock, @MockBean, @Spy, @SpyBean, @InjectMocks의 차이
@Mock: Mockito에서 단위 테스트를 위한 Mock 객체 생성. 행위 검증이 가능하다.
@MockBean: Spring Boot 테스트 환경에서 Mock 객체를 사용하기 위해 Bean을 Mock으로 교체한다.
@Spy: 실제 객체를 사용하면서 일부만 Stubbing을 할 수 있다.
@SpyBean: Spring Boot 테스트 환경에서 Bean을 Spy 객체로 교체한다.
@InjectMocks: @Mock과 @Spy로 생성된 객체를 테스트 대상 객체에 자동으로 주입해준다.
테스트 환경의 독립성 유지에 대한 고민
테스트의 독립성을 유지하는 것이 얼마나 중요한지를 다시 한번 느낄 수 있었다.
테스트 데이터가 @BeforeEach로 설정되면 모든 테스트에서 공유되는 데이터로 사용될 수 있다.
하지만, 테스트가 추가되거나 변경되면 해당 데이터가 정확히 어떤 테스트에서 필요한 것인지 혼란을 초래할 수 있다.
개인적으로는 각 테스트에서 필요한 데이터를 명시적으로 작성하는 방식이 더 명확하고 안전하다고 생각한다.
특히 예외적인 상황을 테스트하거나, 특정 요구사항을 검증할 때 명시적으로 데이터를 정의하는 것이 더 적합하다고 판단했다.
Spring REST Docs와 Swagger
Spring REST Docs와 Swagger는 문서화를 위한 좋은 도구들이다.
둘 다 장단점이 존재하므로, 팀의 환경과 목적에 맞게 적절히 선택하는 것이 중요하다고 생각한다.
Spring REST Docs: 코드 기반으로 문서를 자동으로 생성하며, 정확성과 신뢰도가 높다.
Swagger: UI 기반의 문서화가 가능하고 사용자가 직접 API를 테스트할 수 있는 장점이 있다.
회고와 느낀 점
이번 강의를 통해 테스트의 중요성과 모킹의 활용 방법을 깊게 배울 수 있었다.
특히, 단위 테스트와 통합 테스트를 구분해서 작성하는 방법을 익힌 것이 큰 성과라고 생각한다.
테스트 코드를 작성할 때 각 레이어의 특징을 이해하고, 적절한 테스트 방법을 적용하는 것이 중요하다는 것을 느꼈다.
또한, Mock 객체를 사용할 때는 항상 ‘정말 잘 모킹이 되었는가?’ 라는 의심을 가지고 테스트를 설계해야 한다고 생각한다.
앞으로는 테스트를 작성할 때도 더 효율적이고 의미 있게 작성하도록 노력해봐야겠다.
댓글을 작성해보세요.
