테스트를 작성할 수 밖에 없는 사람들에게
목차
1. 이 글을 작성한 이유
2. 이게 무엇인가?
3. 무엇을 해주는가?
4. 결론
이 글을 작성한 이유
테스트는 짜증난다.
한번쯤은 테스트 작성에 프로덕션 코드 작성보다 더 오랜시간을 사용한 경험이 있을 것이다. 테스트 작성이 오래 걸리는 건 높은 확률로 무언가 문제가 있다는 신호이다. 하지만 문제는 찾기도 어렵고 개인이 해결하기 어렵다. 결론은 결국 울며 겨자먹기로 시간을 내서 테스트를 작성해야 한다. 피할 수 없다면 즐겨야한다는 말이 있지 않은가. 그런 당신을 위한 짜증을 줄여줄 원숭이 한 마리가 있다.
이게 무엇인가?
픽스쳐 몽키는 임의로 객체를 생성해주는 오픈소스 라이브러리이다. 자바와 코틀린에서 사용할 수 있다. 당신은 객체를 일일이 생성하는 대신 중요한 일에 집중하라. 픽스쳐 몽키와 함께라면 작성하는 코드 양이 준다. 작성하는 코드 양이 줄어 테스트 작성 시간을 단축할 수 있다. 심지어 손목에 부담이 줄어 개발자 수명이 더 늘어난다
사람의 개입이 줄면서 실수할 지점도 줄어든다. 예를 들어, 생성자를 통해 객체를 생성할 때 생성자의 파라미터 순서를 잘못 입력할 수 있다. 누가 그런 실수를 하냐고 핀잔을 주고 싶겠지만, 무아지경 코딩, 숙취 코딩을 하면 실수할 수 있다.
만약 당신이 시간외수당을 받을 수 있는 환경이고 용돈이 부족하다면 픽스쳐 몽키는 추천하지 않는다. 객체를 일일이 생성하면 시간이 잘 가고 가끔 실수하여 시간을 더 쓸 수 있다. 다른 의미로 시간은 돈이다.
⛏️ 무엇을 해주는가?
모든 형태의 타입 생성
픽스쳐 몽키는 당신을 위해 거이 모든 객체를 생성한다. 특수한 경우에만 사용하는 복잡한 타입도 문제없이 생성한다. 상속 관계가 존재하는 객체, 인터페이스를 구현하는 익명 객체, 순환 참조가 존재하는 객체 , 제네릭을 가지는 객체 등. 옵션을 추가하지 않아도 기본적으로 생성할 수 있다.
일부 특수한 타입 외에 현재 픽스쳐 몽키를 생성할 수 없는 타입은 없다. 만약 당신이 그런 타입을 발견한다면 픽스쳐몽키 이슈에 제보하면 다음 버전부터 생성할 수 있게 될 것이다. 하지만 다수의 사용자에게 필요없는 타입을 생성해야 하는 경우에는 옵션을 통해 생성하는 걸 권장한다. 픽스쳐 몽키는 옵션을 통해 얼마든지 확장할 수 있다.
다만 타입의 생성 방법에 따라서 옵션을 변경해줘야할 수 있다. 예를 들면, 생성자가 파라미터를 가지고 있는 경우와, 없는 경우, 파라미터가 모든 필드를 포함하는 경우 모두 다른 생성 방식을 사용해야 한다. 타입 생성방식을 고려하지 않아도 되는 옵션도 존재하는데, 성능이 다른 옵션에 비해 나쁠 수 있다.
상속 관계가 존재하는 객체
인터페이스를 구현하는 익명 객체
순환참조가 존재하는 객체
제네릭을 가지는 객체
객체 기본 형태 잡기
"이상한 값을 생성해주는 거 아니야?"
엔터프라이즈 환경에서 사용하려면 생성하는 임의 값이 실제로 입력될 수 있어야 한다. 예를 들어, 돈을 나타내는 타입은 음수가 되면 안된다. 생성 범위는 매우 복잡하고 환경마다 달라 사용자가 정할 수 있어야 한다. 픽스쳐 몽키에서 사용자가 원하는 값의 범위를 지정하는 두 가지 방법이 있다. 첫 번째는 Bean Validation 어노테이션을 추가하는 방법이다. 두 번째는 옵션을 설정하는 방법이다.
첫 번째 방법은 Bean Validation 어노테이션을 추가하는 방법이다. 프로덕션 코드에서 검증이 필요한 경우에 사용할 수 있다. 픽스쳐 몽키는 테스트를 위해 프로덕션 코드를 변경하지 않는 방향을 지향하고 있다. 만약 검증이 필요없다면 두 번째 방법 사용을 추천한다.
두 번째 방법은 register 옵션을 사용하는 방법이다. 생성하는 타입의 정수 필드가 1부터 100까지만 유효한 값이라고 가정하면 다음과 같이 옵션을 설정할 수 있다.
테스트 케이스마다 다른 객체 생성
"실제 엔터프라이즈 환경에서는 사용할 수 없을 것 같은데?"
테스트 작성을 도와줄 라이브러리를 찾았지만 실제 회사에서 사용할 수 없었던 경험을 해본 적이 있을 수있다. 이유는 알고 있다. 실제 엔터프라이즈 환경의 객체는 복잡하다. 비즈니스 정책을 객체로 표현하려면 복잡한 객체가 더 복잡해진다. 복잡하기 때문에 고정된 픽스쳐 (Fixture)를 만들 수 밖에 없다고 생각할 것이다.
비즈니스 정책이 존재하기 때문에 같은 타입의 객체도 테스트 케이스마다 다른 형태를 가질 수 있다.
Foo가 가지는 state의 값이 notNull인 필드를 결정하는 케이스를 생각해보자. state가 a면 fieldA가 notNull이고, b면 fieldB가 notNull이다. 테스트 케이스마다 state 값이 달라지는 경우 테스트하기 어렵다. 테스트 케이스마다 필요한 값이 다르다. 따라서 테스트 케이스마다 객체를 다르게 생성할 수 있어야 한다.
픽스쳐 몽키는 테스트 케이스마다 객체를 다르게 생성하는 방법을 제공한다. 위의 예에서 만약 테스트 케이스에서 state가 a인 객체가 필요하다고 가정해보자. 다음 같이 설정하면 된다. 설정한 `state`, `fieldA` 외의 모든 필드는 임의로 생성한다.
위의 테스트에서 state와 fieldA, fieldB, fieldC 사이 관계가 노출되는 걸 싫어하는 사람이 있을 수 있다. 픽스쳐 몽키에서는 모든 게 가능하다. 다음과 같이 사용하면 된다. fixtureMonkey 인스턴스에서 생성하는 모든 Foo는 객체 내 규칙에 따라 생성한다.
이미 정의해놓은 픽스쳐를 확장해서 사용할 수도 있다. 다음과 같이, 다른 테스트 케이스에서 사용하던 foo를 가져와서 실패 테스트를 작성할 수 있다.
state 가 A일 때 fieldA가 아닌 다른 필드가 notNull이여서 실패하는 케이스픽스쳐 몽키는 개인과 팀의 선호도에 따라 테스트 케이스마다 유연하게 사용할 수 있다. 심지어 모든 필드를 고정해서 고정된 픽스쳐를 생성하는 용도로 사용할 수 있다. 객체 생성이 필요한 모든 테스트에서 픽스쳐 몽키를 사용할 수 있다. 만약 불가능한 케이스가 있다면 픽스쳐몽키 이슈에 올려보자!
결론
테스트를 작성한다면 픽스쳐 몽키 사용을 고려해보자.
처음에 말했듯이 테스트는 짜증난다. 중요하지만 어렵고 시간이 많이 든다. 픽스쳐 몽키는 당신이 테스트에 사용하는 시간을 줄여주려고 한다. 픽스쳐 몽키는 테스트를 작성하는 대부분의 사람들에게 유용한 도구다. 쉽게 사용할 수 있고 편리함을 준다. 이번 글은 픽스쳐 몽키 소개를 위해 작성했다. 다음 글에서는 픽스쳐 몽키를 왜 사용해야 하는가에 대해서 적어보려고 한다.
