테스트를 작성하고, 커버리지를 95% 이상 유지하며 깨달은 것들 (테스트 철학, 전략, 노하우, Jacoco)

Contents

• 시작하며
• 커버리지는 거들뿐
• Repository 클래스는 무엇을 테스트해야 하지?
• 메인 클래스는 무엇을 테스트해야 하지?
• Unit 테스트와 Integration 테스트 커버리지
• Jacoco의 Exclude는 살아있어야 한다.
• Instruction과 Branch 커버리지
• 마치며

 

---

 

시작하며

기분좋은 초록색 막대

 

 이번에는 F-Lab 멘토링 과정에서 진행한 프로젝트에서 테스트 코드를 작성하고, 커버리지 95% 이상 유지하며 깨달은 것들을 공유하려고 합니다. 테스트는 프로젝트의 무엇을, 어떻게, 왜 작성했는지 고수준 개념(concept)으로 다루겠습니다. 

 

 *** 이번 블로그는 독자분들이 자바, 스프링, 스프링 부트의 매우 기초적인 개념을 알고 계신다는 전제하에 작성했습니다.

 

---

 

커버리지는 거들뿐

 커버리지는 정말 거들뿐입니다.

 같은 브랜치, 인스트럭션을 가지고도 테스트를 작성 방법은 여러 가지가 존재합니다. 높은 커버리지를 유지하면서 애플리케이션, 또는 개발 프로세스의 품질 또한 유지하고 싶다면 테스트 작성 시 한 번씩 다음 질문을 던져야 한다고 생각합니다.

 이 테스트는 어플리케이션의 무엇을 지키기 위한 것인가?

 

---

 

Repository 클래스는 무엇을 테스트해야 하지?

현재 프로젝트의 구조

 Repository 클래스 테스트 작성 방법은 있지만 무엇을 테스트해야 하는지를 설명하는 리소스는 찾기 힘듭니다. 형식적인 테스트 작성은 자칫하면 JPA 나 MyBatis 라이브러리를 테스트하고 있을 가능성이 있다는 것입니다. 비어있는 데이터베이스의 테이블에 MemberRepsotory.save()를 실행하면 테이블에 저장되는 것은 어딘가 부족해 보입니다.

 

 마틴 파울러는 Repository의 역할을 이렇게 정의합니다.

Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects
- from "P of EAA", Martin Folwer

 저는 Repository 의 역할을 이렇게 해석했습니다.

Repository는 서비스의 핵심 로직과 데이터베이스 사이를 중재한다.
- JHK

 TDD와 아키텍처 여러 리소스들을 찾아본 후 제가 내린 결론은 "Repository 클래스는 애플리케이션의 persistence 레이어와 데이터베이스와의 계약 세부사항(Contract)을 테스트해야 한다"입니다. RDBMS을 예로 들면 각 Column 값의 범위, 관계 Relations 들을 테스트 해야 합니다. 이해를 돕기 위해 몇 가지 예시를 소개하겠습니다.

 

예시 1) 

1. 비즈니스 요구사항은 Member의 Address 길이가 100자를 넘지 않는 것입니다.
2. DBA는 Member 테이블의 Address 칼럼 제약을 VARCHAR 100으로 설정했습니다.
3. 그렇다면 Repository 가 101자의 주소를 담아 INSERT 문을 실행하면 에러가 발생해야 합니다.
4. 그래서 아래와 같이 SQLException을 발생시킨다는 부분을 테스트로 작성합니다. 

// 길이가 101인 address를 가진 멤버 인스턴스 생성
Member member = new Member(길이가 101인 address)

// member를 저장하려고하면 SQLException.class를 뱉는다.
 Assertions.assertThrows(
    SQLException.class,
    () -> memberRepository.save(member));

 

예시 2)

1. RDMBS의 관계 테스트해보겠습니다.
2. Member는 신규 생성 시점부터 소속 MemberGroup이 존재해야 합니다.
3. DB 관점에서 1:N = Member : MemberGroup 관계가 Foreign Key 를 통해 형성되어있습니다.
4. 신규 Member를 존재하지 않는 MemberGroup의 아이디와 함께 저장한다면 SQLException을 발생시켜야 합니다.

// 유효하지 않은 데이터 객체 생성
MemberGroup mg = new MemberGroup(존재하지 않는 그룹이름);
Member member = new Member(mg, ...);

// SQLException 이 발생해야 정상
 Assertions.assertThrows(
    SQLException.class,
    () -> memberRepository.save(member));

 

이처럼 데이터베이스 세부사항의 테스트를 작성해서 큰 도움을 받은 사례를 잠깐 공유합니다.

 현재 프로젝트 중반부 쯤입니다. 당시 MyBatis의 xml 매퍼를 작성해서 사용하고 있었고 내장 기능의 차이로 MySQL에서 MariaDB로 전환이 필요했습니다. 다행히 커버리지를 100%로 유지한 상태였기 때문에 일단 데이터베이스를 전환하고 테스트를 돌렸습니다. 실패하는 테스트들을 확인하고 해당 부분의 코드 몇 군데 수정하니 몇 시간 채 안되어 데이터베이스를 전환할 수 있었습니다.

 

---

 

메인 클래스는 무엇을 테스트해야 하지?

메인메서드

 메인 클래스는 애플리케이션의 시작점, main 함수를 포함한 클래스입니다. 보통 TestCoverage 툴 적용 예시를 보면 메인클래스는 커버리지 스코프에서 제외시키는 경우가 많습니다. 하지만 메인 메서드 테스트를 통해서도 얻을 수 있는 게 정말 많다고 생각합니다. 오히려 경우에 따라 메인 메서드가 heavily-tested 된 부분이 될 것이라고 생각합니다.

 메인 메서드 SpringApplication.run() 메서드를 가지고 무엇을 어떻게 테스트할 수 있을까요?  main 메서드를 실행하면 무슨 일이 발생할까요? 애플리케이션 컨텍스트가 올라옵니다. 스프링 컨테이너를 구성하고 설정된 Bean 들을 생성합니다. main 함수를 통해 어플리케이션 콘텍스트, Spring 프로파일에 따른 설정 정보,@PostConstruct 적용된 메서드의 동작/실패 케이스 등을 테스트할 수 있습니다. 

 

메인 메소드 테스트가 도움이되는 경우

 예를 들어 사이트 apple와 사이트 banana가 존재합니다. 개발자는 나름의 생각을 가지고 설정 파일을 사이트별로 분리합니다 application-apple.yml 파일과 application-banana.yml 파일을 생성합니다. 사이트가 어딘지에 따라 다른 형식으로 입력받는 경우를 테스트할 수 있습니다. 

 저는 위와 같은 방식을 통해 스프링 프로필 별 main 설정 정보를 테스트했습니다. 프로필에 따라 스프링 부트의 내장 몽고 DB 사용을 위한 AutoConfiguration 클래스의 적용 여부가 달라지는 경우가 있었기 때문입니다.

 

여러 프로필중 일부에만 적용된 설정정보

 그래서 아래와 같이 default 프로필은 BeanCreationException.class가 발생하고, production에서는 발생하지 않는지를 테스트로 작성했습니다. 프로젝트 환경설정이 자주 바뀔 수 있는 프로젝트 초기 단계에 아래 테스트를 통해 많은 도움을 얻었습니다. 무심코 변경한 설정 정보가 콘텍스트 실행 결과에 어떤 영향을 미치는지 확인할 수 있었기 때문입니다. 

 

 

---

 

Unit 테스트와 Integration 테스트 커버리지

내가 느끼는 Unit Test와 IntegrationTest의 성격차이

 우아한 중계서버의 모든 모듈은 Unit 테스트와 Integration 테스트가 존재하고 Jacoco 테스트 커버리지를 적용합니다.

 Unit 테스트, Integration 테스트, 그리고 Jacoco 테스트 커버리지 이 세 가지를 저글링 하는 과정에서 깨달은 부분들은 다음과 같습니다.

 

1. Unit 테스트는 Integration 테스트와 물리적으로 분리되어야 한다.

 Integration 테스트 커버리지와 Unit 테스트 커버리지를 혼합하는 것은 반칙입니다. Integration 테스트는 스코프가 너무 넓기 때문입니다. 자바의 대표적인 테스트 커버리지 툴인 Jacoco는 기본적으로 filepath 기반으로 커버리지를 측정하기 때문에 만약 Integration과 unit 테스트를 어노테이션 기반으로 분리했다면 별도 Gradle.sourceSet으로 분리해야 합니다.  

 

2. 한 가지만 고르라면 Unit 테스트 커버리지.

 우아한 중계서버의 경우 Unit 테스트의 커버리지만 관리합니다. 이유는 1번 항목 와 동일하며 @SpringBootTest 어노테이션을 사용하는 클래스는 대부분 Integration 테스트라고 생각하면 되겠습니다.

 

 

---

 

Jacoco의 Exclude는 살아있어야 한다.

보통 테스트하지 않는 부분들도 테스트할 명분과 방법을 찾으며 느낀 점은 이렇습니다.

테스트는 못하는 게 아니라 (지금은) 안 하는 것

 미리 이야기하자면 충분한 이유가 있는 경우 테스트 Exclusion은 오히려 필수라고 생각합니다. 너무 테스트에 집중하면 비효율적인 경우도 많기 때문입니다. 그리고 지금 테스트할 필요가 없는 부분이 있을 수도 있습니다. 중요한 것은 exclusion(제외)한 이후 잊혀지지 않는다는 것.

 그래서 주변에 보이는 exclusion 클래스들을 그대로 작용시키지 않고 반대로 접근했습니다. 테스트 커버리지 exclusion이 없는 상황에서 시작했습니다. 프로젝트를 진행하는 과정에서 테스트하기 비효율적으로 보이는 부분들은 다음 질문들에 답해가며 테스트 exclusion에 포함시켰습니다.

• 외부에서 충분한 테스트를 거친 라이브러리인가? 예시로 Lombok의 getter, setter는 충분한 테스트를 거쳐서 우리 IDE에 옮겨진다
• 이 클래스/기능이 의존 라이브러리가 아니라면, 이 클래스는 어떤 목적으로 작성했으며, 어떤 상황에 대비해 테스트를 작성해야 할까?
• 이 클래스/기능이 테스트하지 않아도 된다고 생각한다면, 어떻게 동작하는 클래스/기능이며 그렇게 동작하지 않을 경우 어떤 문제가 발생할 것인가? 그 문제는 어떻게 커버되는 건가?

 저도 분명 테스트했다고 설명한 메인 클래스를 프로젝트 환경에 격변이 일어나고 있는 최근에는 테스트 커버리지에서 잠시 제외했습니다.

 

---

 

Instruction과 Branch 커버리지

 

  알다시피 Instruction과 Branch 커버리지는 차집합이 존재하는 커버리지 유닛입니다. 그래서 제 생각은 이렇습니다.

기왕이면 Instruction 과 Branch 커버리지 둘 다 적용하자

 Instruction 커버리지를 100% 유지하면 커버리지 유닛의 관점에서 상당히 편향된, Opinionated 한 결과가 발생할 수 있다고 생각합니다. 기왕이면 한 가지 타입의 커버리지를 100%로 만들기보다는 instruction AND branch coverage를 모두 95%로 만들고 기왕이면 100%를 유지하는 것이 더 thorough 한, 철저한 테스트라고 생각합니다.

 

---

 

마치며