오늘은 상품에 대한 수정, 논리 (soft) 삭제 기능을 하였고, 오후에는 mokito 라는 의존성을 추가하여 Mock 객체를 사용하여 테스트를 진행하였다.
진행하면서 겪었던 점을 정리해 보겠습니다.

(상품에 대한 수정 기능에 대한 내용은 변경감지와 병합에 대해 알수 있었다.)

변경감지 : 엔티티 클래스에서 수정 메소드 생성
엔티티 팩토리 merge : 위험성이 있음

➡ 변경 감지와 merge에 대해서는 다음 블로그에서 다뤄야겠다.

오전

논리 (soft) 삭제 기능 적용

처음으로 논리 삭제가 무엇인지 왜 논리 삭제를 해야되는 것 인지 알아보겠습니다.

• 삭제에는 크게 2가지 방법이 있습니다.
  ➡ 물리 삭제, 논리 삭제

➡ Controller 클래스

@DeleteMapping("/{id}")
    public RsData softDeleteProduct(
    	@PathVariable(name = "id") Long productId) {
        
        productService.softDeleteProduct(productId);
        return RsData.of(DELETE_SUCCESS_PRODUCT, "delete");
    }

물리 (Hard) 삭제는 데이터베이스의 row 자체를 삭제하는 방법입니다.

• 등록된 상품을 select 하고, 등록된 상품과 연관된 이미지를 select 하여 등록된 상품을 조회합니다.
• @DeleteMapping 의 요청으로 delete 쿼리 문이 실행 되며, 데이터베이스의 row가 실제로 삭제되게 됩니다.
  

논리 (Soft) 삭제는 데이터베이스의 row를 삭제하는 것이 아닌 삭제 여부에 대한 필드를 추가하여 여부를 판단 합니다. (삭제 시간, 논리값 (false, true) 등으로 판단)

update 쿼리 문이 실행 되게 됩니다.

• UPDATE 쿼리 문이 실행 되게 되며, deleted_at의 필드에 삭제 요청이 들어온 시간을 저장하게 됩니다.
  (deleted_at 필드는 엔티티 클래스에 미리 작성하여 데이터 베이스에 매핑 해야 됩니다.)
  

➡ 논리 삭제를 구현하는 방법에는
@SQLDelete(sql = "UPDATE 엔티티 클래스 이름 SET 필드 이름 = CURRENT_TIMESTAMP where id = ?")의
엔티티 클래스에 @SQLDelete() 어노테이션을 작성하여, 엔티티 삭제가 발생하였을때 delete 쿼리문대신 커스텀 하여 매핑 할수 있습니다.

마무리

그래서 언제 논리 삭제를 사용해야 될까 ?
➡ 실제 데이터를 삭제하지않고 삭제 이력을 추적해야 되는경우, 복구 가능성이 필요한 경우 등등의 조건에서 사용하여 데이터를 보호 할수 있습니다.

오후

Mokito 테스트

• 가짜 객체를 만들어 사용할수 있게 지원하는 테스트 프레임워크 이며, build.gradle의 아래와 같이 의존성 추가가 필요 합니다.
• 보통 Controller와 Service 단을 테스트 하기 위해 사용합니다.
  (의존성을 주입 받아야 하는경우, mokito를 사용하여 가짜 객체를 주입)

dependencies {
    testImplementation 'org.mockito:mockito-core:5.2.0'
}

service 단 에서 의존성 주입을 하는 객체는 @Mock 어노테이션을 통해 가짜 객체로 만들어 줄수 있습니다.

@InjectMocks 어노테이션은 주입을 받을 클래스를 작성하여 사용 합니다.

@ExtendWith(MockitoExtension.class) // Mock 객체 초기화를 위한 어노테이션
class ProductServiceImplTest {
 	@InjectMocks // 주입을 받을 클래스
    private ProductServiceImpl productService;

    @Mock // 주입할 객체
    private ProductRepository productRepository;

    @Mock // 주입할 객체
    private ImageRepository imageRepository;


	@Test
    void test() {
    	// 테스트 코드 작성..
    }
    
}

Repository 테스트

• @DataJpaTest 어노테이션은 스프링 부트의 JPA 테스트를 하기 위해 사용하는 어노테이션 입니다.
• 실제 데이터베이스와 통신 하지않으며, H2 데이터 베이스를 default로 테스트 하게 됩니다.

build.gradle 의 추가하여 인메모리 DB를 구축해야 합니다.

dependencies {
    runtimeOnly 'com.h2database:h2'
    
    // ... 추가 의존성
}

@DataJpaTest
class ProductRepositoryTest {
    @Autowired
    private ProductRepository productRepository;

    @DisplayName("상품 저장 확인")
    @Test
    void create_Product() {
        Product product = Product.builder().productName("강아지 사료")
                .price("25_000")
                .content("유통기한 1년 남은 사료입니다.")
                .build();

        Product saveProduct = productRepository.save(product);
        assertThat(saveProduct.getProductName())
                .isEqualTo(product.getProductName());
    }
}

마무리

Mock 객체를 사용하여 테스트를 코드를 이번 프로젝트에서 처음 시도 해보았습니다. 어색하고, 서투르지만 추가로 만들 기능들에 대해 계속 사용해보며 익숙해 지는게 목표 입니다.

REFERENCE

https://velog.io/@sussa3007/Spring-JUnit-Mockito-%EA%B8%B0%EB%B0%98-Spring-%EB%8B%A8%EC%9C%84-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EC%BD%94%EB%93%9C-%EC%9E%91%EC%84%B1 (mokito 테스트 참조 블로그)