우아한테크캠프 Pro 3주차 인수 테스트 주도 개발 미션을 진행한 내용과 후기를 정리해본다.

이번 미션의 목표

저장소 및 PR

인수 테스트 미션을 진행하면서 궁금했던 부분을 리뷰어님께 문의드려서 답변받은 내용이다.

제공되어 있는 코드에는 픽스처를 Map을 사용하고 있는데, Dto로 변경하여 개발을 하였다. Map을 선호하는 개발자도 있지만 Map 사용하게 되면 API 스펙에서 파라미터가 변경되는 경우에 이를 인지하기 어려울 수 있다. 그리고 Dto는 외부에 노출되어 있는 API 스펙의 일부분으로 보고 사용하면 된다고 생각했다.
인수 테스트는 어떤 기술을 사용해서 구현했는지도 중요하지만, 더 중요한 것은 다양한 관점을 가진 팀원들 중 누가 보더라도 이해할 수 있는 수준이어야 하기 때문에 리팩터링이 더 중요하다. (한글 메서드명 사용 등)
인수 테스트 검증을 위해서 다른 인수 테스트를 사용하는 것도 가능하다.

findById() 로 데이터를 조회하는 경우는 생각보다 잦다. 이 기능을 public 메서드로 만들어 놓는다면 다른 도메인에서 유용하게 사용이 가능하다.

일반적으로 알려진 예외를 사용할 경우 원래의 예외 처리 로직과 혼동이 되는 케이스가 발생될 수 있다. 이런 경우에는 다른 예외를 사용하거나 커스텀 예외를 만들어서 사용자.

테스트의 범위를 어디까지 잡아야 하는지 고민이 됐었는데, 그 부분이 어느 정도 해소된 것 같다.

기본적으로 인수 테스트를 구현하고, 비즈니스 로직이 도메인 레이어에 응집력 있게 구현이 되어 있다면 비즈니스 로직에 대한 테스트는 도메인 테스트로 커버가 될 것 같다. 단순한 CRUD에 대한 애플리케이션 레이어에 대한 테스트는 불필요하다고 생각한다.

Optional로 반환할 경우 호출하는 쪽에서 매번 Optional에 대한 처리를 해줘야 하므로 Null 객체를 반환하도록 하여 불필요한 코드를 줄일 수 있다.