엔티티에 따라 진행방식이 달랐던 유닛테스트 - upqnu/prj_uc GitHub Wiki

[ 결과적으로는 엔티티(Entity)에 따라 진행방식이 달랐던 유닛테스트 ]

:point_right: 엔티티 현황

  • 사용자(Member)
  • 팀(Team) ; 프로젝트를 관리하는 가장 큰 단위.
  • 팀 구성(TeamSetting) ; Member와 Team이 다대다 양방향 연관관계이므로, 연결테이블로 TeamSetting 엔티티 생성.
  • 진행상황(Progress) ; 팀을 칸반보드로 관리한다고 가정하면, 진행상황은 칸반보드의 Column이라고 보면 됨. Todo, WIP, Done 등의 진행상황을 의미.
  • 티켓(Ticket) ; 진행상황(Progress) 내 개별 작업.

이 중 API가 작성된 클래스는 Member, Team, Progress, Ticket 이다. 따라서 API에 대한 테스트 코드(클래스)도 위 이 4개의 클래스에 대해 작성되었다.

:dart: 진행방식을 다르게 하는 것은 dummy data!

서버를 구동시키면 그 즉시 dummy data가 생성된다. 이는 '테스트'를 위해 생성하는 것이다. postman에서의 테스트, Spring boot의 테스트를 조금 더 편하게 진행시키고 싶기 때문이다.

생성되는 dummy data는 member 20명, team 4개, teamSetting 15개(각 팀에서 사용자들이 팀 멤버인지 아닌지 확인 가능), progress 2개, ticket 5개이다.

유닛테스트 진행은 다음과 같이 계획을 하게 되었다 :

  • MemberController, TeamController의 유닛 테스트 : dummy data를 활용하지 않고 테스트 진행
  • ProgressController, TicketController의 유닛 테스트 : dummy data를 활용하여 테스트 진행

Dummy Data를 만들어 놓고 Member, Team의 API에는 활용하지 않는 것은 이상하게 보이겠지만...

이 서비스의 목적인 '효율적 프로젝트 관리'의 출발점이 사용자(member)가 팀(team)을 생성하는 것이다. 따라서 Member, Team의 API 테스트는 member, team의 CRUD를 직접 구현하겠다고 생각을 했다.

이런 관점에서 Member와 Team 없이는 생성할 수 없는 Progress, Ticket의 테스트는 dummy data를 기반으로 진행해도 충분히 검증된 테스트라고 판단했다.

:key: 일종의 결론? dummy data를 활용한 테스트 코드 작성이 훨씬 쉬웠다...

TeamController에는 4개의 API가 작성되어 있다. 테스트의 경우, [팀장 - 팀원 - 팀 멤버가 아닌 사용자]의 권한이 각각 다르기 때문에 API별로 2~3개의 테스트가 진행될 수도 있다.

하지만 테스트 메서드의 숫자가 늘어나는 것보다 더 어려웠던 것은 테스트 메서드별로 준비(given) 과정에서 작성해야 할 코드가 매우 많아진다는 것이다. (이 때 했던 생각들은 여기에서 확인할 수 있다.)

예를 들어, 팀원이 자기 속해있는 팀을 조회하는 기능의 테스트 코드의 준비(given) 과정은 다음과 같다.

  • 팀장 및 팀원이 될 멤버(member) 생성
  • 팀장이 될 사용자의 로그인 및 액세스 토큰 발행
  • 팀장이 팀 생성
  • 다른 사용자를 팀원으로 초대
  • 초대받은 사용자가 로그인 및 액세스 토큰 발행
  • 초대받은 사용자가 초대를 수락(그 즉시 팀원이 됨)

해당 코드는 여기에서 확인할 수 있다

위 6가지 준비 과정 중 2번의 로그인은 같은 로직에 의해 진행되므로, TeamControllerTest 클래스에는 테스트 메서드 외에도 5개의 메서드를 준비해야 하는 것이다.

:arrow_heading_down:

반면 TicketControllerTest 클래스는 내부에 테스트 메서드를 제외하고 준비(given) 단계에서 필요한 메서드는 단 1개 뿐이다.

준비 단계에서 필요한 member(의 로그인 및 사용자 인증), ticket을 포함하고 있는 team 및 progress가 dummy data에 이미 준비되었기 때문이다.

우여곡절 끝에 모든 API에 대한 유닛 테스트를 완료하게 되었다. 향후, 테스트 코드에 대한 리팩토링 또는 다른 프로젝트의 테스트 코드를 작성할 때 dummy data를 어떻게 활용할 것인지, 유닛 테스트를 넘어 통합 테스트를 어떻게 진행할 것인지가 다음 과제라고 생각한다.