-
양방향 연관관계를 갖는 객체를 테스트하는 어려움Today I Learned 2022. 11. 2. 23:59
게시글 목록과 관련된 백엔드 구조를 작성하는 과정에서 먼저 구성한 모델들을 Controller가 Service로부터 데이터를 전달받았을 때 DTO를 정상적으로 반환하는 과정을 수행하는지 검증하는 테스트를 작성하고 있었다.
테스트 코드를 작성하면서 동작 검증에 사용할 테스트 데이터들을 정의하던 중, 양방향 연관관계를 갖는 Entity 인스턴스를 생성자로 정의해 마련하는 과정이 너무 어렵게 느껴졌다.
기록해놓는 것을 잊은 관계로 다음의 예시 코드들을 통해 문제 상황을 살펴보도록 하자. 다음의 코드는 특정 사용자의 id를 받아 게시글을 찾는 Service의 메서드를 호출해 결과를 DTO로 반환하는 Controller의 메서드이다.
다음의 사용자, 게시글 Entity 객체들을 테스트에 활용하려 했다. 사용자와 게시글은 사용자 입장에서 양방향 일대 다 관계를 맺고 있다.
다음과 같이 테스트 코드를 작성하는 과정에서 문제점이 느껴졌다.
테스트에 사용할 데이터를 미리 정의해놓기 위해 Post 인스턴스에도 값을 정의해주고, User 인스턴스에도 값을 부여해줘야 했다. 이때 두 인스턴스가 서로 관계가 있는 인스턴스임을 나타내기 위해 user에는 해당 user를 멤버로 갖는 post 컬렉션의 정보를, 각각의 post에는 user의 정보를 부여해야 했다. 그 과정을 이행해보려 한 결과 위의 소스코드와 같이 서로가 물고 물리는 관계가 나타나 정상적으로 데이터들을 정의할 수가 없었다.
문제를 해결하는 방법으로는 연관관계를 단방향으로만 정의하는 방법이 존재했다. 그러나 문제 해결을 위해 단방향 연관관계를 적용하는 것은 테스트를 통과시키기 위해 효율성이 좋지 않은 구조를 선택하는 것이었다.
@OneToMany 단방향 연관관계를 적용할 경우 Many 객체에서 One 객체를 알 수 있는 방법이 없으므로 Many 쪽의 Entity에서 One 객체를 조건으로 하는 데이터 삭제 쿼리를 실행할 경우 오버헤드가 발생한다는 사실을 확인한 이상 단방향 매핑을 선택할 수는 없었다.
노아 트레이너님께서 오후에 안내사항을 통해 객체에 컬렉션 멤버가 포함되지 않도록 모델을 구성하라는 안내를 주셨다. @OneToMany와 @ManyToOne에 대해 학습한 것들을 사용할 수 없게 된 점은 아쉽지만 데이터 모델링 이슈로 인한 테스트 코드 작성의 어려움을 조금은 덜고 모델 설계에 좀 더 집중할 수 있게 된 것 같아 프로젝트 방향성 측면에서 아쉬운 점만 있지는 않는 것 같다.
Reference
'Today I Learned' 카테고리의 다른 글
테스트가 너무 크고 복잡하면 로직을 다시 돌아볼 필요가 있다 (0) 2022.11.04 스프린트 주간 2주차 중간점검 (0) 2022.11.03 POST 요청으로 연관관계를 갖는 객체들의 데이터 생성하기 (0) 2022.11.01 모델 구조 설계는 데이터베이스 설계가 아닌 객체 설계 먼저 (0) 2022.10.30 양방향 @ManyToMany 관계를 갖는 모델을 정의하고 데이터 가져오기 (0) 2022.10.29