SCC 프로젝트 테스트 커버리지 관리 회고

 

- 'SCC 프로젝트 테스트 커버리지 관리 회고'를 STAR 프레임워크를 기반으로 진행해보았습니다.

 

- STAR 프레임워크는 특정 상황에서 목표를 달성하기 위한 전략적인 접근 방식으로,

  주로 문제 해결 및 성과 평가 등에서 사용됩니다.

  이 프레임워크는 상황(Situation), 작업(Task), 행동(Action), 결과(Result)의 네 가지 핵심 요소로 구성되어 있습니다.

 

1) 상황(Situation) 

• 회사의 기존 프로젝트에서는 테스트 커버리지를 별도로 관리하지 않았습니다.
  이로 인해
  (1) 프로덕트 전반에 대한 테스트 코드의 시각화가 어려웠고,
  (2) 일정이 급한 경우에는 테스트 코드 개발이 생략 되기도 하였습니다.   
  
  특히, (2)로 인해서 프로덕트의 잠재적인 버그 발생 가능성이 높아질 수 있다는 문제점이 있었습니다.
  
  
  

2) 작업(Task)

• 신규 프로젝트에 Jacoco를 도입하여 테스트 커버리지를 관리하기 시작했습니다.
  (참고 아티클: 우아한테크블로그 - Jacoco)
• 단, 테스트 커버리지를 통해 관리되는 클래스들을 주로 비즈니스 로직이 집중되어 있는 
  '서비스 클래스'들을 중심으로 진행했습니다. 
  -> 이렇게 한 이유는
  (1) 비즈니스 로직이 집중되어 있는 서비스 클래스가 버그의 발생 가능성/버그 발생 시 side effect가 가장 큼
  (2) 개발 생산성의 관점에서 테스트 코드 작성에 대한 ROI(Return On Investment)를 고려  

 

 

3) 행동(action)

• 프로젝트 빌드 시, Jacoco를 통해 테스트 커버리지 확인
  -> 목표 테스트 커버리지 미달 시, 추가적인 작업을 통해 테스트 작성
• 주기적인 테스트 코드 리팩토링

 

4) 결과(result)

(1) 테스트 코드에 대한 가시성 향상

• 테스트 커버리지를 도입한 후, 프로젝트 내에서 어떤 클래스에 얼마나 많은 테스트 코드가 작성되어 있는지 쉽게 파악할 수 있었습니다.
  이를 통해 추가적인 작업이 필요한 부분을 명확히 식별할 수 있었고, 테스트 코드의 관리와 보완이 용이해졌습니다.

 

5) 보완할 점

(1) 테스트 코드의 질적인 측면

• 테스트 커버리지는 테스트 코드의 질적인 측면을 보장하지 못합니다
  -> 따라서, 단순히 테스트 커버리지 목적에 초점을 맞추기보다는,
       에러 케이스에 대한 유효한 테스트 코드를 잘 작성하는 것이 더 중요합니다.

(2) 테스트 커버리지 목표 치 하향 조정 

   -  신규 프로젝트의 경우, 요구 사항의 변경이 자주 발생하고, 그로 인해 테스트 코드도 같이 수정해야 합니다.

       이 경우 테스트 코드가 오히려 생산성을 일정부분 저해할 수 있다는 점을 경험하게 되었습니다.

 

   -  따라서, 신규 프로젝트의 경우 테스트 커버리지 목표치를 하향 조정(ex) 40%)하고,

      이후에 프로젝트가 안정화되었을 때, 목표치를 좀 더 높이는 것이 바람직할 수 있다고 판단하였습니다.