작성한 질문수 9

0

안녕하세요, m3252 님!

1. 강사님은 classicist를 지향한다고 했는데, classicist의 단위 테스트는 데이터베이스와 같은 공유 의존성을 테스트 대역(mock)으로 대체해야 한다는 것으로 알고 있는데 유연한 사고(?)로 classist를 지향하지만 통합 테스트로 단위를 확인하는 것을 좋아한다 정도로 정리하면 좋을까요?
아니면 H2를 사용했으니 테스트 대역을 운영환경보단 빠른 환경으로 교체했으니 여전히 단위 테스트라고 생각을 하시는 걸까요?

음 이해하신 의미가 조금 반대인 것 같은데요. 간단하게 이야기해서 Classicist는 테스트 더블을 지양하고 최대한 실제 클래스의 유기적인 관계를 그대로 테스트하자는 입장이고, Mockist는 테스트 더블로 테스트하고자 하는 대상으로부터 다른 의존성을 모두 끊어내고, 정확히 테스트하고자 하는 부분만 떼어내서 테스트하자는 입장입니다.

Service 테스트를 예로 들자면, 강의 중에 진행했던 것처럼 Service에서 사용하는 Repository(다만, 테스트 환경이니 경량화된 H2 DB로 갈음해서 사용)를 그대로 사용해서 테스트하는 것이 Classicist가 지향하는 바라고 볼 수 있겠고요.
만약 Mockist라면 Repository도 H2처럼 구동하는 실재가 아니라, FakeRepository라던가, mock 객체를 이용해서 흉내만 내는 테스트 더블을 사용해서 Service의 순수한 로직만 테스트했을 것입니다.

2. service 레이어를 통합 테스트로 안 짜는 팀에서 classicist를 지향한다면 DB에 대한 의존성을 어떻게 대체하는지 간단한 예제라도 보여주실 수 있을까요? ㅠ

질문이 잘 이해가 가지 않습니다..ㅎㅎ 통합 테스트를 안짜는 팀에서 classicist를 지향한다면 강의 중에 보여드린 방식처럼 H2를 사용한 스프링 통합 테스트를 작성해볼 수 있지 않을까요? :)

감사합니다. 🙂

0

안녕하세요, 인프런 AI 인턴입니다.

m3252님의 질문에 대해 답변 드리겠습니다.

1. Classicist의 접근 방식은 실제 의존성을 사용하는 것에 더 가깝기 때문에, 강사님은 유연한 사고로 Classicist를 지향하지만 통합 테스트를 선호하여 실제와 비슷한 환경에서의 단위 테스트를 수행하는 것을 좋아하신다고 해석하는 것이 적절합니다. H2 같은 인메모리 데이터베이스를 사용함으로써, 실제 데이터베이스를 사용하는 것보다는 더 빠르게 테스트 환경을 구성할 수 있지만, 이를 단위 테스트의 일부로 보는 관점은 개발자나 팀의 테스트 방향성에 따라 달라질 수 있습니다.

2. 서비스 레이어의 통합 테스트를 진행하지 않는 팀에서 DB와 같은 외부 의존성을 대체하는 일반적인 방법은 mock 객체를 사용하는 것입니다. 예를 들어, Spring Boot는 @MockBean을 통해 Spring 컨텍스트 내의 특정 빈을 모의 객체로 쉽게 대체할 수 있으며, 이를 통해 DB 접근을 담당하는 repository 레이어를 모의 객체로 대체하여 서비스 레이어의 비즈니스 로직을 독립적으로 테스트할 수 있습니다. 예제는 특정 코드 없이는 설명이 제한적일 수 있지만, 간단히 말해서, 서비스 메소드에서 데이터베이스 호출을 담당하는 부분에 대해 mock 객체를 주입하고, 원하는 행동 또는 데이터 반환을 모의 객체가 하도록 설정하여 테스트를 진행할 수 있습니다.

Spring Boot와 관련된 더 깊은 테스트 방법론에 대해서는 Spring Boot Reference Documentation에서 통합 테스트와 단위 테스트에 대한 자세한 지침을 참고하시는 것이 좋을 것 같습니다.

질문에 대한 답변이 도움이 되길 바랍니다. 추가로 궁금하신 점이 있으시다면 언제든지 문의해주세요.