[ATDD, 클린 코드 with Spring 6기] 3주차 정리

1. 개요

1) 통합 테스트

통합 테스트의 다양한 정의

1. 단위테스트의 조건에 하나라도 부합하지 않으면 통합테스트다
2. 자신이 혼자 만든 것을 확인하는 것은 단위테스트며, 다른 이들과 같이 만든 것을 확인하는 것은 통합테스트다
3. 개별 단위 간의 유기적인 연결을 확인하는 것 → 본 강의에선 이를 통합 테스트로 규정했다

통합 테스트의 넓은 의미와 좁은 의미

• 넓은 의미: 전체적인 모듈들이 잘 동작하는 지를 검증하는 것
• 좁은 의미: 각각의 요소들만 잘 동작하는 지를 검증하는 것 (=서로 다른 모듈 간의 통합이 잘 이루어지는지 검증)

넓은 의미 vs 좁은 의미

 

2) 관리 의존성 vs 비관리 의존성

• 관리 의존성
  • 내 애플리케이션을 통해서만 상태를 바꿀 수 있는 것
    • ex) 내 애플리케이션에만 연결된 DB
  • 실제 환경을 구축해서 통합 테스트를 하는 편이 좋음
• 비관리 의존성
  • 다른 애플리케이션에서도 상태를 바꿀 수 있는 의존성
    • ex) Github API, 아임포트 등
  • 대역을 사용해서 통합 테스트를 하는 것이 수월함

 

의존성 테스트 방법

1. 실제 외부 의존성 사용
2. Stub으로 대체
3. Fake로 대체 → 이번 주차 미션에선 Fake를 사용해서 비관리 의존성을 대체했다

 

 

2. 3주차 리뷰

1) 피드백

모든 의존성을 객체 참조로 구현하면 발생할 수 있는 문제들

1. 객체 간의 결합도가 높아진다
2. 다른 객체로의 탐색이 가능해진다
3. DB 조회 또는 ORM 사용 시 복잡도가 증가한다

간접참조 vs 직접참조

• 객체 참조를 피하는 방법엔 간접참조가 있다
  • 참조 객체의 ID만을 보관하는 방법 (참고)

• 직접참조는 라이프 사이클이 동일한 객체를 묶을 때 유용하다
  • 따라서 같은 라이프 사이클을 가진다면 직접참조로 구현하자
  • 밀접한 관계는 직접참조로 구현하며, 그게 아니라면 간접참조로 구현하자

• 관련 영상 링크

 

2) PR

• https://github.com/next-step/atdd-subway-favorite/pull/379
• https://github.com/next-step/atdd-subway-favorite/pull/394
• https://github.com/next-step/atdd-subway-favorite/pull/427

 

3) 리뷰 정리

• 무분별한 유틸 클래스 사용을 지양하자
  • 유틸 클래스는 갓 클래스가 될 수 있으므로 정말 필요한 경우가 아니라면 적절한 객체에게 해당 역할을 부여하자
• 하드코딩된 값 사용을 지양하자
  • 처음에 응답을 검증하기 위해 ParameterizedTest를 작성할 때 string으로 된 @ValueSource를 사용했으나, @EnumSource로 수정하여 코드가 바뀌었을 때 컴파일 타임에 변경을 확인할 수 있도록 수정했다
• 테스트 클래스 내에서 인스턴스 변수를 만들기보단 given문 하에서 지역 변수를 선언하는 것을 우선적으로 고려하라
  • 테스트가 늘어날수록 인스턴스 변수가 많아지면 관리가 어렵고 가독성이 저하된다
  • 또한 테스트 케이스끼리 인스턴스 변수를 공유하면 격리에 영향을 줄 수 있다

 

 

3. 느낀 점

테스트를 짜다 보면 비관리 의존성에 대한 고민이 많아지게 된다. 특히 도메인이 크면 클수록 그 고민은 커진다. 현재 내가 회사에서 진행중인 프로젝트도 여러 외부 API를 호출하는 형태로 구성되어 있어서 테스트하기가 여간 까다로운 것이 아니었다. 그 와중에 이번 미션을 통해 인사이트를 얻을 수 있었다(미션처럼 Fake 객체를 사용한 게 아니라, Stub을 사용하긴 했지만). 이제 어느덧 한 주만이 남았는데, 마지막까지 최선을 다해서 수료까지 달려보자.