테스트 코드

[hwicode]

목적

• 코드를 정확하게 작성한 것을 검증합니다.
• 리팩토링을 해도 테스트가 유지되게 만듭니다.
• 최소한의 테스트로 최대한의 가치를 얻습니다.
• 코드가 지속적으로 성장할 때, 문제가 생기지 않았음을 검증해야 합니다.

테스트 작성 방법

• 코드를 작성하고 테스트 코드를 바로 작성합니다.
• 도메인 레이어에서는 행위를 통해 동작을 검증하는 단위테스트를 작성합니다.
• 서비스 레이어에서는 외부 시스템과의 연결을 검증하는 통합 테스트를 작성합니다.
• 컨트롤러 레이어에서는 유효성 검사와 예외 처리, 서비스 호출 여부, HTTP 요청이 제대로 작동하는지 검증하는 Mock MVC 테스트를 작성합니다.
• 마지막으로 전체 API가 제대로 작동하는지 검증하는 엔드 투 엔드 테스트를 REST-Assured를 통해 작성합니다.

테스트 작성 시 고려 사항

• 테스트를 최대한 아래 계층에서 작성합니다.
• 각 레이어에서 진행하는 검증을 다른 레이어에서 중복해서 검증하지 않습니다.
• 서비스 레이어는 외부 시스템과의 연결을 검증하므로 레포지토리를 직접 사용했습니다.
• 외부 서비스로 요청을 보낼 때에는 Mock을 사용했습니다.
  ex) DB, Redis는 직접 사용하고 OAuth Client는 Mock을 사용했습니다.

결과

• 총 662개의 테스트 코드를 작성했습니다.
• 테스트 코드를 작성해도 버그는 발생합니다.
  • 내가 생각하지 못한 방식으로 코드가 동작하는 경우가 있기 때문입니다.
  • 그래서 탐색적 테스트도 중요합니다.
• 기능을 변경하거나 추가할 때, 문제점을 미리 발견할 수 있었습니다.
  • JPA 프록시로 인한 문제

아쉬운 점

• 테스트 코드에 상속을 사용하여 애플리케이션 컨텍스트를 재사용하지 않아서 테스트 속도가 느려졌습니다.
• DatabaseCleanUp로 테스트 데이터를 초기화해서 테스트 속도가 느려졌습니다.
  • DB 초기화 방법 : @Transactional, @DirtiesContext, TRUNCATE, deleteAllInBatch()
  • 다음에는 deleteAllInBatch() 메서드 사용해보기
  • 참고 사항 : DatabaseCleanUp 사용 이유
• 테스트 픽스처 활용이 미흡했습니다.
  • 텍스트 픽스처에서 도메인 생성 로직을 하나로 추상화하기 (도메인 필드의 기본값을 가지게 만들기)
  • 테스트 클래스 내부에 private 팩토리 메서드 활용하기
  • 주의사항 : 테스트 클래스에서는 필요한 필드만 사용하기 -> 필요하지 않는 필드는 메서드 내부에서 기본값으로 설정

• 엔드 투 엔드 테스트는 핵심 비즈니스 시나리오를 검증하는 용도로만 사용해야 했습니다.
  • 기존 방식은 컨트롤러 테스트와 중복이 발생했습니다.
• 프레임워크와 라이브러리에 대한 테스트 코드는 적어도 한 개는 작성해야 했습니다.
  • 프레임워크에 커스텀하게 추가하는 코드도 테스트했어야 했습니다.
• 도메인을 테스트할 때, 생성자로 id를 추가해서 도메인을 식별하는게 더 나은 것 같습니다.