작성한 질문수 28

3

안녕하세요, 양성빈 님!

제가 테스트할때는 repository부분의 쿼리메서드나 jpql로 작성한 코드들은 따로 테스트를 하지 않고 QueryDSL같은 외부 라이브러리를 사용할때만 단위 테스트를 진행합니다.

아주 단순한, 쿼리가 예측되는 메서드라면 비용을 고려하여 테스트를 스킵할 수도 있겠으나, 결국 런타임 시점에 생성되는 SQL 쿼리를 검증하지 않고는 기능을 보장하기가 어렵습니다.

• 쿼리 메서드 : Spring data JPA에서 제공하는 기능으로 결국 SQL를 생성해주는 것이니, 복잡한 쿼리일수록 예측이 어려울 수 있습니다.

• JPQL : 문자열로 작성되기에, 단순한 오타 등 동작하지 않을 가능성이 쿼리 메서드보다 더 큽니다.

• QueryDSL : 컴파일 타임에 어느 정도 기능 보장을 해주나, 마찬가지로 최종 생성되는 SQL에 대한 검증이 필요합니다.

그래서 사실 어떤 방식을 사용하든, 런타임 시점의 기능을 보장하기 위해서는 테스트가 필수라고 생각해요.

그리고 비즈니스 레이어에 대해서는 위의 repository를 mocking하여 사용하고 컨트롤러 부분에서 통합테스트를 진행합니다.

위에 말씀드린 이유로 인해, 복잡한 Repository의 쿼리 뿐만 아니라, 다양한 Repository, 비즈니스 로직이 얽힌 서비스 계층에서 Repository를 mocking하여 테스트하는 것은 저는 조금 위험할 수 있다고 생각해요.
저도 테스트를 작성하지 않고 기능을 개발했을 때, 쿼리가 실제 생각한대로 동작하지 않아 결국 시간을 더 사용하게 되었던 경험이 많습니다.

Controller 단에서 Repository를 포함한 전체 통합 테스트를 한다고 하더라도, Repository 단위 레이어 테스트로 보장할 수 있는 케이스를 가장 바깥 레이어의 통합 테스트 케이스로 커버하는 것은 비용 측면에서도 비효율적인 것 같아요 ㅎㅎ

도움이 되셨기를 바랍니다.
감사합니다 🙂