인프런 커뮤니티 질문&답변

dncjf64님, 안녕하세요!

테스트 코드 관련해서는 개인적인 기준이 있기는 한데, 갑자기 글로 풀어내자니 쉽지 않네요.. ㅎㅎ

상황마다 모두 달라질 수 있는 점은 참고해주시고, 두서 없이 간략히 서술해 봅니다.

• 별다른 분기 없이 절차적으로 내려가는 코드는 단위 테스트 굳이 작성하지 않음

• 분기에 대해서는 커버리지를 최대한 높이고자 함. 하지만 눈으로 대충 봐도 명확히 드러나면 굳이 테스트하지 않음

• 분기가 많거나 복잡하면, 테스트 코드 짤 때에도 테스트 데이터 세팅하는게 복잡해짐

• 그 경우에는 코드를 메소드 또는 클래스 단위로 분리하고, 분리된 메소드 또는 클래스에 대해 단위 테스트 작성함

• 그러면 기존 작성하던 테스트와 테스트하고자 하는 코드는 아주 간소화될 수 있음. 자연스럽게 관심사 분리가 일어남.

• 외부 API 또는 DB 연동은 멱등하지 않거나 격리된 환경이 아니라면, 굳이 테스트 코드를 만들고 계속 돌리진 않음

• 그냥 최초에 테스트 코드로 한번 호출해서 검증해보고 비활성화 해둘 때도 있음

• 또는 testcontainer를 활용해서 격리된 환경으로 테스트하기도 함

• 또는 연동을 위한 특정 모듈이나 격리된 환경에서 테스트 코드 작성해서, 단순 연동 확인에 대해서는 제한적으로 수행되도록 함

• 통합/e2e테스트도 특정한 기준이 있다기 보단, 외부 연동이 있거나 전반적인 흐름이 연계되는지 꼭 확인해보고 싶을때 작성함

• 이것도 격리된 환경이 아니거나 멱등하지 않으면 비활성화 해둠

• 웬만하면 단위 테스트로 커버하는 편. 결국에 각 기능의 조합으로 API를 구성하다보니, 잘 돌아가는 단위 테스트 조합한 것이 통합테스트와 크게 다를 것 없을 때가 많음

• 물론, 그래도 통합테스트가 필요한 상황에는 짬. 다만, 그 범위와 경계는 고려가 필요함.(예를 들어, 컨트롤러의 반환 객체가 의도한 직렬화 방식으로 처리되는지 테스트하려는데, 모든 컨트롤러마다 이걸 테스트할 필요는 없음. 이를 위한 부분만 따로 분리해서 테스트를 만들면 됨. 패키지가 아니라 모듈로 분리하면 이게 조금 더 편함)

• 일정은 테스트 코드를 짜는지 마는지와 크게 상관 없음

• 하지만 이 기능에 대한 스펙이 확정된 상황이 아니거나, 구조를 가까운 시일 내에 리팩토링할 예정이라면 세세하게 만들진 않음

• 그 경우에는 어차피 다시 짜야 하기 때문. 나중에 확정되고 짜도 됨.

• 엄청나게 아주 긴급하게 배포를 해야 하는 상황 + 해결이 아주 명확한 것으로 보이면 딱히 테스트 안 만들음

• 그래도 그런 경우는 잘 없음. 대부분의 경우에는 테스트를 짜든지, 직접 실행해보든지 함. 수정 사항이 잘못되었거나 다른 지점에서 연달아 장애가 발생할 수도 있기 때문.

• 테스트를 코드로 자동화하는 것도 좋지만, 그냥 직접 손으로 실행해보고 눈으로 확인하는걸로 충분할 때도 있음

• 물론, 장기적으로 계속 테스트를 확인해야하면 테스트 코드는 당연히 필요함

일단 생각나는대로 적어보았습니다! 절대 정답은 아닙니다.

그리고 Mockito는 저도 단위 테스트를 작성할 때 자주 활용하는데요, 충분히 검증이 된다고 생각합니다!

단, mock으로 만든 행위와 상태는 이미 잘 돌아간다는 전제가 있어야 합니다.

이미 그 기능에 대해서는 다른 테스트로 검증을 끝낸 상황인데,

다른 기능을 단위 테스트하면서 굳이 이중으로 검증할 필요가 없습니다.

굳이 끌어온다면 단위 테스트라고 부르기도 모호해지고, 의존성/테스트데이터 세팅도 상당히 귀찮아지고요.

테스트 범위의 경계를 잘 이해하고, 각 범위에 대해 테스트를 문제 없이 처리할 수 있으면 충분한 검증이 되는 것 같네요.

연계해서 테스트해야 할 필요성이 있다면, 그 경우에는 통합 테스트로 처리하든, 경계의 범위를 넓힐 수도 있는 것이고요.

이러한 테스트의 경계는, 단위테스트든/통합테스트든 동일하게 적용되는 내용이라 잘 이해해두면 좋을 것 같네요.

(예를 들어, 외부 API를 연동해서 테스트하고자 하는 경우에, 그 테스트를 처리해야하는 주체는 내가 아닐 수 있다는 것. 외부 API의 동작을 테스트하는게 아니라 정상적으로 커넥션이 맺어지는지만 확인해도 충분할 때가 많음. API는 애플리케이션 프로그래밍에 필요한 인터페이스라서, 타 팀에서 추상화되어있는 내부 동작까지 알 필요도 없고 우리가 테스트할 이유도 없음)

테스트는 중요하기 때문에 아주 좋은 질문입니다!

근데 이런건 직접 경험하면서 자신만의 관점이 생길 수도 있고, 사람 또는 환경마다 생각이 달라질 수 있어서 딱히 정답이라고 할 수는 없습니다!

저도 구체적인 상황이 주어지거나 시간이 조금 더 지나면 관점이 바뀔 수도 있고요.

참고 정도로만 받아들이시면 충분할 것 같네요!

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

테스트 코드 작성에 대한 고민을 많이 하신 것 같네요! 다양한 테스트 종류와 방법에 대한 고려는 소프트웨어의 안정성을 높이기 위한 중요한 부분입니다. 질문 주신 내용에 대해 간단히 정리해 보겠습니다.

테스트 코드 작성 기준

1. 단위 테스트:

   • 테스트의 가장 기본적인 형태로, 작은 부분(주로 메서드나 함수)이 적절히 작동하는지 확인합니다.
     
   • 순수 객체에 대한 테스트를 통해 로직의 정확성을 보장하려는 목적이 있습니다.
     

2. 통합 테스트:

   • 여러 구성 요소가 정상적으로 상호 작용하는지 확인합니다.
     
   • 서비스의 핵심 로직이나 복잡한 비즈니스 로직의 경우 통합 테스트를 통해 시스템 전반의 행동을 검증할 수 있습니다.
     

3. E2E 테스트:

   • 사용자 관점에서 전체 시스템이 정상적으로 작동하는지를 확인합니다.
     
   • 시간이 많이 소요될 수 있으므로, 핵심 시나리오에 대해 작성하면 좋습니다.
     

Mockito를 이용한 테스트

• Mockito를 이용한 단위 테스트는 실제 객체와의 의존성을 줄이면서도 필요한 검증을 수행할 수 있어 유용합니다.
  
• verify를 통해 메서드 호출 여부를 검증하는 것이 주된 사용 목적이며, 로직의 복잡도에 따라 적절히 활용해야 합니다.
  

테스트 작성 시 고려 사항

1. 일정:

   • 테스트 작성에 우선순위를 두는 것은 중요합니다. 일정이 촉박할 경우, 핵심 로직에 대한 단위 테스트를 우선하여 작성하면 좋습니다.
     
   • 시간이 넉넉하다면 통합 테스트나 E2E 테스트도 포함하여 전체적인 안정성을 높이는 것을 고려할 수 있습니다.
     

2. 데이터 세팅의 번거로움:

   • 스프링의 @DataJpaTest와 같은 어노테이션을 활용하여 적절한 데이터 상태를 유지하면서 테스트를 수행할 수 있습니다.
     
   • 필요 시 Testcontainers를 이용하여 실제 DB 환경과 유사한 조건에서 테스트를 진행하는 방법도 있습니다.
     

더 많은 정보가 필요하시다면, 아래 관련된 유사 질문의 답변을 참고해 보실 수 있습니다:

• 테스트 코드 작성의 기준과 우선순위에 대한 논의
  

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.