JIE0025

✅ 개요일반적으로 우리는 서비스단의 단위 테스트를 작성할때, repository를 mock(가짜객체)으로 만들고, DB로의 흐름을 끊어버리는 단위테스트를 작성했었다. 최근에 외부 API를 사용하기위해 webClient를 사용했는데 이때 서비스 단에서 WebClient를 주입 받아, mock객체를 repository가 아닌 다른 대상에 처음 적용해 보게 되어 이 글을 적게 되었다. 데이터베이스에서 어떤 값을 가져와 일반적인 자체만을 검증했었다면 이번 기회로 더 다양한것을 검증해보게 된 계기가 될 것 같다. ✅ WebClient 자체를 mock객체로 만들어서, 모킹해도 된다. 이 방식에는 문제점이 있다. 아래 예제 코드를 보면 webClientMock.get()에 대한 처리부터, requestHeadersU..

✅ 개요 스프링 기반의 프로젝트에선, 코틀린을 사용해도 기존의 테스트 프레임워크인 JUnit, Assertion, Mockito를 동일하게 사용할 수 있지만.. 그래도 코틀린에 어울리게 코틀린스럽게(?) 테스트코드를 짤 수 있도록 돕는 도구들이 존재한다. (MockK와 Kotest) 이 중 오늘은 MockK를 알아보고 어떻게 단위테스트를 하는지 간단하게 알아보자. ✍️ 기술 비교 MockK외에도 코틀린을 위한 테스팅 프레임워크에는 Kotest라는 것도 있다. Kotest는 코틀린진영에서 가장 많이 사용되는 테스팅 프레임워크이다. 다양한 테스트 레이아웃을 제공하고 Kotlin DSL 스타일의 Assertion도 제공된다. Junit과 호환성이 있어 기존의 Junit과 마이그레이션 하기 용이함. 예제 코드 ..

✅ Apache JMeter Apache JMeter는 Apache Software Foundation에서 개발되었다. 오픈소스 로드 테스팅 툴로 다양한 성능 테스팅이 가능하다. * (웹서버, DB, FileSystem 등 서비스/프로토콜에 대한 테스팅) ✅ 왜 JMeter를 사용하는가? 다양한 Application/Server/Protocol 유형을 로드하고, 성능 테스트가 가능하다. 웹- HTTP/HTTPS (Java, NodeJS, PHP, ASP.NET) SOAP/REST 웹서비스 FTP JDBC를 통한 interface LDAP TCP 자바 객체 메일 - SMTP, POP3, IMAP --- (S) 모든 Java 호환성 Jmeter는 자바 기반의 서비스/ 애플리케이션의 테스팅을 지원한다. CLI..

✅ 문제 요약 통합테스트에서 데이터베이스 이슈 : 각각은 잘 동작하지만 전체 동작시 실패 해결방안으로 @DirtiesContext를 사용했으나, 해당 어노테이션을 사용하면 전체 DB를 초기화하며 빌드 속도가 너무 느리다는 단점이 생겼음 개선 이전 : 총 테스트시간이 2sec, 242ms https://jie0025.tistory.com/385 [Trouble shooting] 통합테스트에서 데이터베이스 이슈 : 각각은 잘 동작하지만 전체 동작시 실패 JIE0025 [Trouble shooting] 통합테스트에서 데이터베이스 이슈 : 각각은 잘 동작하지만 전체 동작시 실패 본문 프로젝트 - FLAG/에러 [Trouble shooting] 통합테스트에서 데이터베이스 이슈 : 각각은 잘 동작 jie0025.t..

통합테스트를 진행하기 위해서는 몇가지 고려할 점이 있다. 데이터베이스 서버를 작동시켜야한다. 테스트가 끝나고 데이터가 지워지지 않기 때문에 다음 테스트시에 해당 데이터를 어떻게 처리할지 데이터베이스 초기화를 진행할지 해당 데이터로 다음 테스트를 진행할지 테스트 순서는 어떻게 정해줄건지 등등 어디까지 검증할것인가? package com.FlagHome.backend.domain.category.integration; import com.FlagHome.backend.domain.category.controller.CategoryController; import com.FlagHome.backend.domain.category.dto.CategoryPostDto; import com.FlagHome.back..

컨트롤러 슬라이스 테스트와 마찬가지로 슬라이스 테스트이므로 서비스 로직이 잘 돌아가는지만 확인하면 되어서 4가지 테스트만 만들어주었다. package com.FlagHome.backend.domain.category.service; import com.FlagHome.backend.domain.category.entity.Category; import com.FlagHome.backend.domain.category.repository.CategoryRepository; import com.FlagHome.backend.global.util.CustomBeanUtils; import org.junit.jupiter.api.DisplayName; import org.junit.jupiter.api.Test..

컨트롤러 단에서 서비스/레포지토리를 거치지 않는, 컨트롤러 자체를 위한 테스트 코드이다. 이 경우, 컨트롤러에 요청이 잘 들어오고 응답이 잘 거치면 되는지 테스트해주면 되기 때문에 CRUD 네가지를 체크해주었다. package com.FlagHome.backend.domain.category.controller; import com.FlagHome.backend.domain.category.dto.CategoryPatchDto; import com.FlagHome.backend.domain.category.dto.CategoryPostDto; import com.FlagHome.backend.domain.category.dto.CategoryResultDto; import com.FlagHome.back..

내가 해볼 수 있는 거의 모든 테스트코드를 적은 것 같다. 일단 첫번쨰는 엔티티를 검증하는 도메인테스트! 엔티티에 대해 값의 추가와 수정만 있으므로 3가지 테스트를 제작했다. package com.FlagHome.backend.domain.category.entity; import org.assertj.core.api.Assertions; import org.junit.jupiter.api.DisplayName; import org.junit.jupiter.api.Test; import static org.assertj.core.api.Assertions.*; import java.util.ArrayList; public class CategoryTest { public Category activityC..

카테고리 수정하는 부분에서 PATCH를 사용하면서 문제가 있었는데, 좀 알아보니까 PATCH용 DTO를 따로 만들고 그러는것 같다.. 카테고리에서 굳이 그럴 필요까지는 없을 것 같아서 PUT으로 바꾸고 테스트를 진행해야겠다. 나중에 PATCH를 쓰는건 연습을 따로 해봐야지.. ✅ GIVEN 일단 data 입력해주고, id가 5인 카테고리의 이름 "카테고리4"를 "ALGORITHM"으로 바꾸기! PUT으로 바꿨기 떄문에 전체 데이터를 보내준다. PUT http://localhost:8080/v1/categories/5 { "name":"ALGORITHM", "categoryDepth":2, "parentId":3 } PATCH는 참고할만한 예제가 많이 없어서 연습이 필요할 듯 하다 ㅠㅠ ✅ 결과 확인 잘 ..

오늘 열심히 테스트코드를 짜다가 핵심 로직이 문제인지, 테스트코드 문제인지 모르는상태로 열심히만한걸 깨달았다. 역시 사람은 생각을 하고 해야해... 따라서 현재 할 수 있는 최선은 1) POSTMAN으로 전부 다 보내보고 기능적으로 문제가 없다면 테스트코드 싹 갈아엎기? 만약 문제가 있다면 로직 바꾸기 (내일..) 2) 이전 글에서 바꾼 파일구조 저렇게 하면 안될것 같으니 피드백 받고 수정하기 (내일) 오늘의 내가 고통받으면서 구현은 했으니 내일의 나는 좀더 편하길...😂 (성공) POST 카테고리 추가 (실패) PATCH 카테고리 수정 왜..안돼..?일단 알았어.... 포스트맨이 이럴땐 고맙다 ㅠㅡㅠ (성공) GET : depth가 0인 카테고리 반환(모든 카테고리 데이터 JSON처리) (성공) DEL..