jjamong blog

상품(product)과 주문(order), 그리고 이 두 테이블 간 연결 테이블인 orderProduct가 있다고 하자. `deleteAllInBatch()` 메서드로 리소스를 정리하는 것과 `deleteAll()` 메서드로 리소스를 정리하는 것의 차이를 알아보자. deleteAllInBatch()먼저 `deleteAllInBatch()` 메서드를 사용해 정리해볼 것이다.@AfterEachvoid tearDown() { orderProductRepository.deleteAllInBatch(); productRepository.deleteAllInBatch(); orderRepository.deleteAllInBatch();} 위 테스트코드 실행 시 발생하는 쿼리는 다음과 같다.Hiber..

테스트 환경의 독립성을 보장하자아래와 같은 테스트 코드가 있다고 생각하자.@DisplayName("재고가 부족한 상품으로 주문을 생성하려는 경우 예외가 발생한다.")@Testvoid createOrderWithNoStock() { // given LocalDateTime registeredDateTime = LocalDateTime.now(); Product product1 = createProduct(BOTTLE, "001", 1000); Product product2 = createProduct(BAKERY, "002", 3000); Product product3 = createProduct(HANDMADE, "003", 5000); productRepository.s..

Test Double 이란?테스트 더블이란 실제 객체를 대신해서 테스팅에서 사용하는 모든 방법을 일컬어 호칭하는 것이다. Test DoubleDummy: 아무것도 하지 않는 깡통 객체Fake: 단순한 형태로 동일한 기능은 수행하나, 프로덕션에서 쓰기에는 부족한 객체 (ex. FakeRepository)Stub: 테스트에서 요청한 것에 대해 미리 준비한 결과를 제공하는 객체. 그 외에는 응답하지 않는다.Spy: Stub이면서 호출된 내용을 기록하여 보여줄 수 있는 객체. 일부는 실제 객체처럼 동작시키고 일부만 Stubbing 할 수 있다.Mock: 행위에 대한 기대를 명세하고, 그에 따라 도작하도록 만들어진 객체 Mocks Aren't StubsMock과 Stub은 다르다. Stub - 상태 검증(Stat..

용어 정리- `MockMvc`: 실제 서블릿 컨테이너 없이도 MVC 동작을 모의(mock)하여 테스트할 수 있도록 Spring에서 제공하는 테스트 프레임워크- `@WebMvcTest`: @SpringBootTest가 전체 빈을 모두 띄우는 테스트 어노테이션이었다면, @WebMvcTest는 컨트롤러 관련 빈들만 띄우는 가벼운 테스트 어노테이션- `@MockBean`: Spring 컨텍스트에서 빈을 모의(mock) 객체로 교체할 때 사용하는 어노테이션 @Mock vs @MockBean@Mock: 스프링 애플리케이션 컨텍스트를 로딩하지 않고도 사용 할 수 있기 때문에, 스프링 애플리케이션 컨텍스트를 사용하지 않는 순수 단위 테스트에서 모의 객체를 생성하는 데 적합 (서비스 테스트)@MockBean: 스프링 애..

@SpringBootTest특징✅ 애플리케이션의 전체 컨텍스트를 로드하여 통합 테스트를 수행한다.✅ 모든 빈(Bean)을 초기화하므로 JPA뿐만 아니라 서비스, 컨트롤러, 기타 의존성까지 포함된다.✅ 내부적으로 @Transactional 어노테이션이 없어, 테스트 후 데이터를 정리하려면 tearDown() 메서드를 직접 정의해야 한다.장단점✅ 장점: 애플리케이션 전체를 테스트할 수 있어 통합 테스트에 적합하다.✅ 단점: 테스트가 무겁고, 실행 시간이 상대적으로 오래 걸릴 수 있다. @DataJpaTest특징✅ JPA 관련 컴포넌트(Repository, EntityManager 등)만 초기화하여 테스트한다.✅ @SpringBootTest보다 가볍고 빠르게 실행된다.✅ 내장 데이터베이스(H2 등)를 활용해 ..

Repository 테스트를 왜 해야할까?1. JPA 메서드가 작성자의 의도대로 쿼리를 생성하고 실행하는지 검증하기 위해개발자는 코드에 기반한 로직이 올바르게 작동한다고 믿을 수 있지만, 실제로 생성된 쿼리가 기대와 다를 수 있다! 2. 미래의 변경 사항에 대비하기 위해현재 JPA를 사용하더라도 향후 QueryDSL, MyBatis와 같은 다른 기술로 변경될 가능성이 있다. Repository 테스트를 잘 구성해 두면, 이러한 변경에도 안정적으로 동작을 검증할 수 있다. Repository 코드@Repositorypublic interface ProductRepository extends JpaRepository { /** * select * * from product * wh..

레이어드 아키텍처사용자 요청이 왔을 때 레이어별로 요청을 처리하자! -> 관심사의 분리관심사를 분리함으로써 책임을 나누고 유지보수하기 용이하게 만들 수 있다. Presentation Layer, Business Layer, Persistence Layer 로 나누고, 이를 3-Tier라고 부르기도 한다.조금 더 자세히 나누고 싶다면 Persistence Layer 하위에 Infrastructure Layer를 두고 4-Tier로 나누기도 한다. Presentation Layer✅ 외부 세계의 요청을 가장 먼저 받는 계층✅ 파라미터에 대한 최소한의 검증을 수행한다. Business Layer✅ 비즈니스 로직을 구현하는 역할✅ Persistence Layer와의 상호작용(Data를 읽고 쓰는 행위)를 통해 ..