어제 완성했던 최소 기능의 게시글 목록 조회, 신청 기능을 테스트하는 테스트 코드에 한 가지 문제가 남아있었다. 테스트 코드에서 사용될 인스턴스들을 만들기 위해 사용하는 fake 메서드만을 봐서는 post나 game, member에 대체 어떤 값을 줘서 fake 인스턴스를 만드려는 건지 알 수 없었다.
그래서 오늘 가장 먼저 수행할 작업으로 객체들이 가진 식별자와 필드를 값 객체로 분리시키는 작업을 계획했다.
필드를 값 객체로 분리시키는 작업은 값 객체로 분리시킬 객체를 @Embeddable 어노테이션이 붙은 객체로 분리하고, 객체 내에서 쓰일 값 객체에 @Embedded 어노테이션을 붙이는 것으로 분리할 수 있었지만, 식별자 필드를 값 객체로 분리시키는 것은 써본 적이 없었기 때문에 값 객체를 쓰는 식으로 분리해도 되는지 질문을 올렸다.
오늘도 생각하지 못했던 부분에 대한 답변이 돌아왔다.
fake 객체를 어떻게 사용해야 쓰기 편리할 것인지 그 이유를 다시 생각해보기 위해 마카오뱅크 풀 스택 강의의 백엔드 소스코드에서 쓰이는 Account의 Fake 메서드를 찾아보고 내 프로젝트에서 사용되는 fake 메서드와 비교했다.
Account의 fake 메서드는 인자로 AccountNumber를 전달받아 나머지 필드 값은 상수로 고정된 Account 객체를 생성한다. 즉 fake 메서드로 만든 Account 인스턴스가 사용되는 곳에서는 accountNumber 값의 구분이 중요하고, 나머지 값들은 테스트에 어떤 영향을 주지 않을 것이라는 점을 짐작할 수 있다. 그렇기 때문에 'accountNumber를 이 값으로 하는 Account 인스턴스를 생성하겠다' 식으로 테스트 코드에서 나타내는 내용을 최소화할 수 있는 것이다.
반면 프로젝트에서 쓰고 있는 fake 메서드는 Game 인스턴스를 구별하기 위해 id를 전달받고 있다. id를 전달하는 이유는 게시글 목록 조회를 수행하는 로직이 Post, Game, Member의 리소스를 서로 일치하는 id를 구분해 조합하는 방식이기 때문이지만, 이 방식으로는 테스트 코드에서 게시글 리스트 객체들의 생성을 위해 fake 메서드를 여러 번 호출해야 하고, 가장 큰 문제는 생성하는 인스턴스들의 id를 서로 일치시키기 위해 직접 숫자를 비교하는 과정을 거쳐야 한다.
게시글 리스트 조회를 위한 fake 메서드에 딱 맞는, 쓰기 편한 인터페이스는 무엇일까.
fake로 꼭 인스턴스를 하나만 생성해야 하나? 싶은 생각이 들었다. fake 메서드 호출 한 번으로 리스트를 만들어서 줄 수 있다면 지금처럼 fake를 여러 번 호출하지 않아도 된다. id도 규칙성을 부여하는 로직을 구현해서 일치시켜줄 수 있겠다는 판단이 섰다.
현재 다음과 같이 fake 메서드의 로직을 구현해보고 있다. 만약 정상적으로 작동한다면, fake 메서드의 사용을 다음과 같이 줄일 수 있고, 테스트 코드를 짤 때 인스턴스들 간에 id 값을 어떻게 맞춰줘야 할지 머리를 굴려가며 고민하지 않아도 된다.
집에 가서 구현을 마저 진행하도록 하자.
cf. 식별자를 값 객체로 분리할 경우 식별자에 @GeneratedValue 어노테이션을 부여할 수 없다. 따라서 식별자를 생성하는 로직을 직접 구현해야 한다.
(다른 객체들에 해당 식별자 값 객체가 삽입이 될 때, 이전의 단순히 숫자 타입의 객체였던 때와는 달리 이제는 실제 식별자로써 작용하는 복합 키가 되기 때문?)
