Fake 테스트 더블 사용하면 느꼈던 점

[mete0rfish]

테스트 더블 중 Fake 기법을 통해 MemberService의 테스트 코드를 작성했습니다. 사용하면서 느꼈던 단점에 대해 이야기하고 싶네요.

1. SetId 관련

Fake Repository 특성 상, Map<>에 데이터를 저장하게 됩니다. 저장 시 ID 값을 AtomicLong을 통해 관리를 하게 됩니다. AtomicLong을 통해 Member의 id를 변경해야하는데, SetId를 사용하게 될 경우 문제가 발생할 수 있습니다.

• 객체의 동일성을 해칠 수 있습니다.
• 무분별한 Setter 사용으로 변경된 지점을 추적하기 어려워질 수 있습니다.

따라서, 저는 두 가지의 아이디어를 생각했습니다.

1. 도메인 엔티티와 영속성 엔티티 분리하기
2. Fixture에서 ID를 생성자로 미리 지정하기
3. Fake 기법 사용하지 않기

이 외에 리플렉션을 사용하는 방법은 매우 비효율적인 방법이므로 배제 했습니다. 일단 2번째 방법을 통해 임시적으로 해결한 상태입니다. 그러나 제가 바라는 방법 1번과 3번 방법입니다. 이번에 Fake 기법을 적용하면서 느꼈던 장점이 크게 없습니다. 스프링 컨텍스트를 이용하지 않기에 빠르고, 데이터베이스를 사용하지 않는다는 것 외에는 장점이 크게 없던 것 같습니다. 따라서, 저는 3번 방법도 좋은 해결책이 될 수 있다고 생각합니다.

만약 프로젝트가 커질 경우, 영속성 엔티티와의 분리하는 작업은 필요하다고 생각합니다. 현재 Member를 보면, JPA 어노테이션으로 매우 가독성이 떨어져 역할보단 필드에 초점이 가는 것이 현실입니다. 따라서, MemberJpaEntity와 Member를 분리하는 작업이 필수불가결하다고 생각해요.

2. CreatedAt 관련

현재 @CreationTimestamp을 통해 INSERT문이 실행 시 자동으로 날짜가 찍히도록 구현되어 있습니다. 그러나 테스트 코드에선 INSERT가 직접 작동하지 않기 때문에 값을 넣기가 매우 애매해졌습니다.

@EntityListeners(AuditingEntityListener.class)
@MappedSuperclass
@Getter
public abstract class BaseEntity {

    @CreationTimestamp
    @Column(updatable = false)
    private LocalDateTime createdAt;

    @UpdateTimestamp
    private LocalDateTime updatedAt;
}

사실 Setter보다 이 문제 해결이 더 어렵습니다. @CreationTimestamp를 제거하거나 리플렉션을 이용하는 방법밖에 없기 때문이에요. 이 또한 도메인 엔티티와 영속성 엔티티를 분리하면 쉽게 해결될 거 같습니다.