Official-Dev. blog

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

최근에 진행중인 대부분 프로젝트에서 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; public train() { // .. 생략 levelUp(); } private void levelUp() { if(exp >= 100) { int count = exp / 100; this.level += count; exp -= 100 * count; } } } 접근이 가능한 메서드에서 테스트 첫 번째는 private method에 대해 테스..

테스트 데이터 생성 테스트 코드를 작성할 때 테스트 데이터는 어떻게 생성해야 할까..? 예시를 들어보자! 유저 조회, 게시글 생성, 댓글 등록 등 기능을 테스트할 때 모두 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 애노테이션을 사용해서 테스트 간 인스턴스와 상태, 설정을 공유할 수 있다. 이를 사용하면 테스트를 더 우아하게 작성할 수 있다. 회원가입 기능을 테스트한다고 가정해보자. 기존의 테스트 ..

문제 발생 최근에 사이드 프로젝트에서 DDD와 CQRS를 적용해서 개발하다가 갑자기 테스트가 깨지는 현상이 발생했다. 각 모델은 다음과 같이 정의되어있었다. (간략화) Command Model @Getter @Entity @NoArgsConstructor(access = AccessLevel.PROTECTED) public class Song { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; private long artistId; private String name; private String image; public Song(long artistId, String name, String image) { this.art..

Spock Spock은 BDD(Behaviour-Driven Development) Framework입니다. TDD프레임워크인 JUnit과 비슷한 점이 많으나, 기대하는 동작과 테스트 의도를 더 명확하고 간결하게 드러내주는 큰 장점이 있습니다. 해당 포스팅에서는 Spock을 사용할 때의 이점과 사용 방법에 대해 알아보겠습니다. 테스트 아래의 MemberTier라는 enum에 대한 테스트를 진행하겠습니다. MemberTier는 각 멤버의 등급마다 다른 할인율을 적용해서 계산해주는 함수형 인터페이스를 필드로 가지고 있습니다. public enum MemberTier { BRONZE("할인율 0%", (price) -> { validPrice(price); return calPrice(price, 0); })..