Official-Dev. blog

해당 포스팅에서는 테스트 시 Web 영역을 어떻게 Mocking 할 지에 대해 다룬다.통합테스트요즘은 단위 테스트를 넘어서 통합테스트 / 인수테스트 / E2E테스트를 많이 구성한다.외부 API를 호출하는 코드가 있다. 해당 로직을 Mocking할 때 어떻게 할 지 생각해보자.주문 시스템 (예시 코드)예시를 위해 제작한 주문 시스템의 코드를 보자.아래는 첫 주문 기능의 진입점인 주문 컨트롤러이다.@RestControllerclass OrderController( private val orderService: OrderService,) { @PostMapping("/order") fun order( @RequestBody orderRequest: OrderRequest, )..

Reactive Programming을 사용할 때 Project Reactor를 주로 사용한다.Reactor는 비동기로 동작하기 때문에 일반적인 테스트 방식으로 검증하기 어렵다. 그래서 Reactor-test 라이브러리를 제공한다.Dependency우선 예시 동작을 위해서 아래와 같은 Dependency를 추가해야한다.testImplementation 'io.projectreactor:reactor-test:3.6.5'Reactive Streams 테스트가 어려운 이유1. 강제 동기화아래 테스트 코드를 보자.@Testvoid test() { // given var expected = IntStream.range(0, 10).boxed() .collect(Collectors.toLi..

새로운 팀에서 테스트를 위한 객체를 생성하는 패턴이나 라이브러리가 필요하게 되었다. 팀원 분이 FixtureMonkey를 추천해주셔서 POC를 진행하게 되었다.FixtureMonkeyFixtureMonkey는 Naver에서 만든 테스트 객체를 쉽게 생성하고 조작할 수 있도록 도와주는 Java 및 Kotlin 라이브러리이다.FixtureMonkey는 한국어 docs를 지원한다. 오픈소스 중에 볼륨도 작은 편이라 한번 읽어보는 것도 추천드린다. 포스팅 내용은 요약 및 검토 정도로 봐주면 좋을 것 같다.https://naver.github.io/fixture-monkey/v1-0-0-kor/docs/introduction이전에 사용하지 않았던 이유FixtureMonkey는 2년 전에 한번 봤었고 적용한다는 블..

최근에 진행중인 대부분 프로젝트에서 Coverage 100%를 지향하면서 단위 테스트(Unit test)도 많아졌다. 해당 포스팅에서는 단위 테스트(Unit test)를 짜면서 얻게된 지식을 일부 공유한다. 리팩토링 내성 리팩토링 내성이란 테스트를 바꾸지 않고 프로덕트 코드를 리팩토링할 수 있어야 함을 의미한다. 쉽게 설명하면 리팩토링 과정에서 거짓 양성이 발생하지 않아야 한다. 거짓 양성: 기능은 잘 동작하는데 테스트가 깨지는 경우 테스트가 구현과 결합도가 높은 경우 발생한다. 단위 테스트를 신뢰할 수 없게 만든다. 프로덕트 코드를 유연하지 못하게 만든다. 구현에 의존하는 경우 최근에 외부 모듈을 사용한 코드에서 모듈 버전을 변경하면서 테스트가 다량 실패하는 현상이 발생했다. POJO 객체만 그대로 사..

최근 TDD에 큰 관심이 생겨서 요즘 핫하다는 ATDD에 대해서와 TDD에 대해 더 깊게 이해하려고 했다. 강연을 찾던 중 NEXTSTEP에 ATDD, 클린 코드 with Spring이라는 좋은 강의 코스가 있는데, 가격이 80만원이다... ㄷㄷ https://edu.nextstep.camp/c/R89PYi5H/ 사실 조금 부담스러워서 우아한 ATDD라는 우아한 테크 세미나 발표가 있다. 아래는 해당 발표 내용을 공부하며 정리한 것이다..! 사실 메모에 가깝다. 인수 테스트 인수 테스트는 시나리오(사용자 스토리) 기반으로 기능을 테스트하는 것이다. 이러한 인수 테스트는 아래의 장점이 있다. 배포 없이 빠른 피드백을 받을 수 있다. 도메인과 서비스 파악에 큰 도움이 된다. QA 절차 없이 테스트 코드만으로..

서비스 단위 테스트를 작성할 때 발생할 수 있는 모든 예외 케이스에 대해 테스트를 하려고 한다. 그러다가 private method를 테스트하고 싶을 때가 있다.어떻게 처리할 수 있는 지 알아보자. 아래는 예시로 사용할 class이다.public class Magician { private int level; private int exp; private void levelUp() { if(exp >= 100) { int count = exp / 100; this.level += count; exp -= 100 * count; } }}Reflection을 활용한 테스트리플렉션을 활용하면 private ..

테스트 데이터 생성 테스트 코드를 작성할 때 테스트 데이터는 어떻게 생성해야 할까..? 예시를 들어보자! 유저 조회, 게시글 생성, 댓글 등록 등 기능을 테스트할 때 모두 Member 생성이 필요하다. 각 테스트에서 일일이 생성자로 Member를 호출해도 되지만, 이를 재사용할 수 있다면 유지보수성이 좋은 코드가 된다. 잘 알려진 방법으로는 아래 2가지가 있다. 1. Test Data Builder 패턴 Test Data Builder 패턴은 Builder를 활용해서 테스트 데이터를 생성하는 패턴이다. public class UserStubGenerator { public static UserStub.Builder generateUserStub() { return UserStub.builder() .lo..

Repository 테스트를 작성할 때 결과를 검증하기 위해서 어떤 도구를 사용해야 할까? 일반적으로 Repository.save() 기능을 테스트한다고 하면, Repository.find_을 사용해서 검증하기 쉽다. 하지만 이는 적절치 않다. 가령, userRepository를 테스트하는 코드에서 userRepository를 사용하면 First 원칙 중 I(Isolated - 고립성)이 깨지게 된다. 그래서 나는 JdbcTemplate을 사용했다. 기존의 코드 @DataJpaTest @AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE) class AccountRepositoryTest { private AccountRe..

MockMvc를 사용해서 Controller를 Test할 때 BDD를 적용해서 가독성을 향상시키는 방법에 대해 알아보자. 기존의 코드를 살펴보자. 기존 기존의 코드는 다음과 같았다. @Test @DisplayName("유저를 생성할 수 있다.") void signup() throws Exception { SignUpRequest signUpRequest = SignUpRequest.builder() .loginId("test123") .password("password12@") .name("TestName") .birthday(LocalDate.of(1994, 2, 10)) .phone("01012345678") .allowToMarketingNotification(true) .build(); mockM..

서비스 단위 테스트(Unit Test)를 작성할 때 구조를 미리 잡는 것도 중요하다. 나중을 생각하지 않고 테스트 코드를 지저분하게 작성했을 때 본인이 혼자 개발한다면 적당한 시기에 리팩토링을 진행할 수 있다. 하지만, 여럿이서 협업을 진행하다 보면 잠깐 자리를 비운 사이 다른 사람이 지저분한 구조를 계속 가져가면서 코드를 많이 작성해서 겉잡기가 힘들어질 수 있다. 해당 포스팅에서는 Nested 클래스를 사용해서 서비스 테스트를 우아하게 작성하는 방법에 대해 다룬다. Nested Tests JUnit5에서는 @Nested 애노테이션을 사용해서 테스트 간 인스턴스와 상태, 설정을 공유할 수 있다. 이를 사용하면 테스트를 더 우아하게 작성할 수 있다. 회원가입 기능을 테스트한다고 가정해보자. 기존의 테스트 ..