[Fixture Monkey] 픽스쳐 몽키로 테스트 코드 작성하기 (Java Spring)

🔹 Fixture Monkey

* 공식 깃헙 : https://github.com/naver/fixture-monkey

* 공식 홈피: https://naver.github.io/fixture-monkey/

Fixture Monkey

기술블로그를 보다가 정식 버전이 출시되었다고 하여 한번 찍먹해보겠습니다. (블로그 링크)

우선 공식 홈피에서 설명을 한번 읽어보았습니다. 

Fixture Monkey는 제어 가능한 임의의 테스트 객체를 생성하도록 설계된 Java 및 Kotlin 라이브러리입니다. 필요한 테스트 픽스처를 쉽게 생성하여 테스트 작성을 간소화하는 데 중점을 둡니다. 기본적인 테스트 픽스처를 다루든 복잡한 테스트 픽스처를 다루든, Fixture Monkey를 사용하면 필요한 테스트 개체를 손쉽게 생성하고 원하는 구성에 맞게 쉽게 사용자 지정할 수 있습니다. Fixture Monkey로 더욱 간결하고 안전하게 JVM 테스트를 수행하세요.

 

 

 

🔹 공식 문서 Getting started 따라 하기

일단 가이드를 따라 해 보겠습니다.

필요조건

• JDK 1.8 or higher (Or Kotlin 1.8 or higher)
• JUnit 5 platform
• jqwik 1.7.3

이런 게 필요하다고 합니다. 저는 JDK 17을 사용합니다.

 

1. 라이브러리 import

#### Gradle ####
testImplementation("com.navercorp.fixturemonkey:fixture-monkey-starter:1.0.0")

#### Maven ####
<dependency>
  <groupId>com.navercorp.fixturemonkey</groupId>
  <artifactId>fixture-monkey-starter</artifactId>
  <version>1.0.0</version>
  <scope>test</scope>
</dependency>

저는 gradle을 사용했습니다.

naver 코드가 내 프로젝트에 있다니 기분이 좋습니다.

 

2. 테스트를 할 객체 만들기

import lombok.Value;

import java.time.Instant;
import java.util.List;

@Value
public class Book {
    Long id;
    String name;
    Integer price;
    List<String> authors;
    Instant createdAt;
}

이런저런 데이터 타입으로 만들어보았습니다.

롬복이 없다면 옆에 링크를 참고하세요. (링크)

 

3. 일반적(?)으로 테스트

import static org.junit.jupiter.api.Assertions.assertEquals;

public class NormalTest {
    @Test
    void normalTest() {
        // given
        Long expectedId = 1L;
        String expectedName = "테스트 책";
        Integer expectedPrice = 10000;
        List<String> expectedAuthors = Arrays.asList("작가1", "작가2");
        Instant expectedCreatedAt = Instant.now();

        // when
        Book book = new Book(expectedId, expectedName, expectedPrice, expectedAuthors, expectedCreatedAt);

        // then
        assertEquals(expectedId, book.getId());
        assertEquals(expectedName, book.getName());
        assertEquals(expectedPrice, book.getPrice());
        assertEquals(expectedAuthors, book.getAuthors());
        assertEquals(expectedCreatedAt, book.getCreatedAt());
    }
}

위에서 만든 Book을 테스트해 보았습니다. 잘 동작합니다.

 

4. 이제 Fixture Monkey를 이용해 테스트해 봅시다.

public class FixtureMonkeyTest {
    @Test
    void fixtureMonkeyTest() {
        // given
        FixtureMonkey fixtureMonkey = FixtureMonkey.builder()
                .objectIntrospector(ConstructorPropertiesArbitraryIntrospector.INSTANCE)
                .build();

        // when
        Book book = fixtureMonkey.giveMeOne(Book.class);

        // then
        assertNotNull(book.getId());
        assertNotNull(book.getName());
        assertNotNull(book.getPrice());
        assertNotNull(book.getAuthors());
        assertNotNull(book.getCreatedAt());


        System.out.println(book);
    }
}

잘 동작했습니다.

 

어떻게 생성되나 궁금해서 print를 찍어봤는데 아래와 같이 나왔습니다.

-- Try 1
Book(id=325, name=丘澭⨀ॲ콘뺽湅╇柺툲늩颷䤨㐂鵿ﺋᓪ齤䥱퓵, price=3060, authors=[て驢曇駈臭磓૑谔닛此蛪隚헎짦征尀눥彃淮ꧩ䬕喝㘧嘖缃죏ᚸ푃烏쵡耣ղ㴊ή诜詽諧䜬읎澛꓊㆕轌桀 襽숼Ἱᴇ䛿ⰶ﹵쭈䟎棜Ξ繧뤭ﶱ줷ᖤ棅쾂ៃ⃞ᕼꓦ샔褞漨ᅞ䱈셉蘍泀翂퓼⺙ﲝ䨞녨ߙ䞼, 糧ᾜ⃧嗜㱝鴨⥐꿷ᓷ㎌ꬎ믵ⶾ⑲ꙡ], createdAt=2023-07-19T10:02:25.892613591Z)
-- Try 2
Book(id=3983871, name=ꉗ薼쁋畲촬渞彄㇠顤뱰㱬ʦㇾ纚㡪鏬⇷‶秵ꂵꊵ加悾蕉ꨆ硁蕊巴, price=871, authors=[ᕇ騷㪿敬ˁ䷖깹횒傜㠱綶舥嶫篊ꤹቧ楃멂뷊춸珦ﰠ삘✄, ᦞᆃ땓岴쇃譲ħ਽മ矓瀵榍阗㜟䄃, 췝㸚튵], createdAt=2024-10-04T04:54:25.860969102Z)

뭔가 엄청난게 들어가는데 인코딩도 좀 문제가 있어보이네요. 뭐 어쨌든 다양한 경우에 대응되는 테스트를 할 수 있을거 같아 든든합니다.

 

그런데 종종 Test가 실패합니다. null이 있다고 하는데, 생각해보니 객체에 NotNull을 명시하지 않아 Monkey가 null 값도 넣어주나 봅니다. 10번 반복해서 돌려보겠습니다.

아 이게 맞지 싶어서 다시 @NotNull을 넣고 테스트 하겠습니다.

 

 

5. Book 객체 수정 후 반복 테스트 (NotNull)

아래와 같이 객체를 수정했습니다.

@Value
public class Book {
    @NotNull
    Long id;
    @NotNull
    String name;
    @NotNull
    Integer price;
    @NotNull
    List<String> authors;
    @NotNull
    Instant createdAt;
}

그리고 테스트를 10번 돌려봅니다.

 

아주 이쁜 초록불이 들어옵니다. print된 결과물도 다양하게 이상한 애들이 들어있습니다.

 

 

 

🔹 결론

객체의 특성에 맞게 다양한 값을 넣어주는 테스트 객체 생성 라이브러리 같습니다. 

문서를 읽어보니 다양한 타입의 객체 생성 가이드도 있고, 원하는 조건을 넣는 방법이 설명되어있습니다.

`객체를 랜덤하게 만드는데, 특정 속성은 어떤 값 중에서 하나를 넣어줘.` 등등 다양한 커스텀이 가능합니다.

이외에도 다양한 방법과 옵션이 있고, 플러그인에 대한 설명도 자세히 있습니다.

문서가 길지 않으니 사용하기전에 충분히 읽어보고 쓰길 바랍니다.

사이드 프로젝트에서 사용하다가 괜찮다 싶으면 회사에 들고가서 써봐야겠습니다.