[Spring Boot] - 테스트코드 적용하기, 테스트 커버리지 확인하기

본 게시물은 유튜브 채널 '어라운드 허브 스튜디오'의 스프링 부트 강의를 들으며 작성한 게시물입니다.
https://youtube.com/@around.hub.studio?si=wB1YEVq-ulj1r4Ao

어라운드 허브 스튜디오 - Around Hub Studio

---

21 ~ 23강

 

 

 

<21 - 테스트코드 적용하기(JUnit, TDD)>

1. TDD

-테스트 주도 개발이라는 의미를 가짐

-단순하게 표현하자면 테스트를 먼저 설계 및 구축 후 테스트를 통과할 수 있는 코드를 짜는 것

-코드 작성 후 테스트를 진행하는 지금까지 사용된 일반적인 방식과 다소 차이가 있음

-애자일 개발 방식 중 하나..

→ 코드 설계시 원하는 단계적 목표에 대해 설정하여 진행하고자 하는 것에 대한 결정 방향의 갭을 줄이고자 함

→ 최초 목표에 맞춘 테스트를 구축하여 그에 맞게 코드를 설계하기 대문에 보다 적은 의견 충돌을 기대할 수 있음

(방향 일치로 인한 피드백과 진행 방향의 충돌 방지)

 

2. JUnit

-자바 진영의 대표적인 테스트 프레임워크

-단위 테스트(Unit Test)를 위한 도구 제공

   *단위 테스트란?

        -> 코드의 특정 모듈이 의도된 대로 동작하는지 테스트 하는 절차를 의미

-모든 함수와 메소드에 대한 각각의 테스트 케이스를 작성하는 것

-어노테이션을 기반으로 테스트를 지원

-단정문으로 테스트 케이스의 기대값에 대해 수행 결과를 확인할 수 있음

-스프링 부드 2.2버전부터 Junit5 버전을 사용

-JUnit 5는 크게 Jupiter, Platform, Vintage 모듈로 구성됨 (빈티지는 이전 버전에서 사용하고 있는, 호환을 위한 모듈)

 

 

3.JUnit 모듈 설명
- JUnit Jupiter

• TestEngine API 구현체로 JUnit 5를 구현하고 있음
• 테스트의 실제 구현체는 별도 모듈 역할을 수행하는데 그 중 하나가 Jupiter-Engine
• 이 모듈은 Jupiter-API를 사용하여 작성한 테스트 코드를 발견하고 실행하는 역할을 수행. 개발자가 테스트 코드를 작성할 때 사용됨

- JUnit Platform

• Test를 실행하기 위한 뼈대
• Test를 발견하고 테스트 계획을 생성하는 TestEngine인터페이스를 가지고 있음
• TestEngine을 통해 Test를 발견하고, 수행 및 결과를 보고함 + 각종 IDE(ex. 인텔리제이 등)연동을 보조하는 역할을 수행(콘솔 출력 등)
• Platform = TestEngine API + Console Launcher + JUnit 4 Based Runner ⇒ 짬뽕 모듈

- JUnit Vintage

• TestEngine API 구현체로 JUnit 3, 4를 구현하고 있음
• 기존 JUnit 3, 4 버전으로 작성된 테스트 코드를 실행할 때 사용됨
• Vintage-Engine 모듈을 포함하고 있음

 

 

 

 

4. JUnit LifeCycle Annotation
- JUnit 5은 아래와 같은 테스트 라이프 사이클을 가지고 잇음 -

 

 

<MAIN ANNOTATION>

@SpringBootTest

• 통합 테스트 용도로 사용됨
• @SpringBootApplication을 찾아가 하위의 모든 Bean을 스캔하여 로드함
• 그 후 Test용 Application Context를 만들어 Bean을 추가하고, MockBean을 찾아 교체

@ExtendWith

• JUint4에서 @RunWith로 사용되던 어노테이션이 ExtendWith로 변경됨
• @ExtendWith은 메인으로 실행될 Class를 지정할 수 있음
• @SpringBootTest는 기본적으로 @ExtendWith가 추가되어 있음

@WebMvcTest(class명.class)

• ()에 작성된 클래스만 실제로 로드하여 테스트를 진행
• 매개변수를 지정해주지 않으면 @Controller, @RestController, @RestControllerAdvice 등 컨트롤러와 연관된 Bean이 모두 로드됨
• 스프링의 모든 Bean을 로드하는 @SpringBootTest 대신 컨트롤러 관련 코드만 테스트할 경우 사용

@Autowired about Mockbean

• Controller의 API를 테스트하는 용도인 MockMVC 객체를 주입 받음
• perform()메소드를 활용하여 컨트롤러의 동작을 확인할 수 있음
• .andExpect(), andDo(), andReturn() 등의 메소드를 같이 활용함
• http 통신을 도와주는 역할

@MockBean

• 테스트할 클래스에서 주입 받고 있는 객체에 대해 가짜 객체를 생성해주는 어노테이션
• 해당 객체는 실제 행위를 하지 않음
• given() 메소드를 활용하여 가짜 객체의 동작에 대해 정의하여 사용할 수 있음

@AutoConfigureMockMvc

• spring.test.mockmvc 의 설정을 로드하면서 MockMvc의 의존성을 자동으로 주입
• MockMvc 클래스는 REST API 테스트를 할 수 있는 클래스

@Import

• 필요한 Class들을 Configuration으로 만들어 사용할 수 있음
• Configuration Component 클래스도 의존성 설정할 수 있음
• Import된 클래스는 주입으로 사용 가능

 

5. 통합 테스트

통합 테스트는 여러 기능을 조합하여 전체 비즈니스 로직이 제대로 동작하는지 확인하는 것을 의미

통합 테스트의 경우, @SpringBootTest를 사용하여 진행

• @SpringBootTest는 @SpringBootApplication을 찾아가서 모든 Bean을 로드하게 됨
• 단점 : 이 방법을 대규모 프로젝트에서 사용할 경우, 테스트를 실행할 때마다 모든 빈을 스캔하고 로드하는 작업이 반복되어 매번 무거운 작업을 수행해야 함 ⇒ 따라서 단위테스트를 많이 수행

*단위테스트 : 프로젝트에 필요한 모든 기능에 대한 테스트를 각각 진행하는 것을 의미

일반적으로 스프링 부트에서는 ‘org.springframework.boot:spring-boot-starter-test’디펜던시만으로 의존성을 모두 가질 수 있음

 

<F.I.R.S.T 원칙>

→ Fast: 테스트 코드의 실행은 빠르게 진행되어야 함

→ Independent : 독립적인 테스트가 가능해야 함

→ Repeatable : 테스트는 매번 같은 결과를 만들어야 함

→ Self-Validating : 테스트는 그 자체로 실행하여 결과를 확인할 수 있어야 함

→ Timely : 단위 테스트는 비즈니스 코드가 완성되기 전에 구성하고 테스트가 가능해야 함

     ⇒ 코드가 완성되기 전부터 테스트가 따라와야 한다는 TDD의 원칙을 담고 있음

 

 

 

 

 

 

 

 

 

<22 - 테스트 커버리지 확인하기>

1. 코드 커버리지
-소프트웨어의 테스트 수준이 충분한지 표현할 수 있는 지표 중 하나

-테스트를 진행했을 때 해당 코드가 실행되었는지를 표현하는 방법

-많은 코드 커버리지 도구가 있으며, 가장 보편적으로 사용되는 Jacoco에 대해 알아볼 것 !

 

2. Jacoco

-JAVA 코드의 커버리지를 체크하는 라이브러리

-작성된 코드의 테스트 커버리지를 측정하는 도구

-런타임으로 테스트 케이스를 실행해 커버리지를 체크하는 방식으로 사용됨

-테스트 코드를 통해 테스트를 실행하고 그 결과를 html, xml, csv 등의 형식으로 report 제공

 

*블랙박스 테스트

→ 소프트웨어의 내부 구조나 작동 원리를 모르는 상태에서 동작을 검사하는 방식. 다양한 값을 입력하여 올바른 출력이 나오는지 테스트 ⇒ 사용자 관점의 테스트 방법

*화이트박스 테스트

→ 소프트웨어의 내부 구조와 동작을 검사하는 테스트 방식. 소프트웨어 내부 소스 코드를 테스트하는 방법. ⇒ 개발자 관점의 테스트 방법

 

-Jacoco pom.xml 파일 설정 방법-

 

 

 

3. Jacoco Rule
-별도의 설정이 없다면 기본 설정으로 되어있음 → 필요에 따라 설정 변경

Element type - 코드 커버리지 체크 기준

• BUNDLE (default) : 패키지 번들
• PACKAGE : 패키지
• CLASS : 클래스
• SOURCEFILE : 소스 파일
• METHOD : 메소드

Counter - 코드 커버리지를 측정할 때 사용하는 지표

• LINE : 빈 줄을 제외한 실제 코드의 라인 수
• BRANCH : 조건문 등의 분기 수
• CLASS : 클래스 수
• METHOD : 메소드 수
• INSTRUCTION (default) : 자바 바이트 코드 명령 수
• COMPLEXITY : 복잡도

Value - 커버리지 정도를 나타내는 지표

• TOTALCOUNT : 전체 개수
• MISSEDCOUNT : 커버되지 않은 개수
• COVEREDCOUNT : 커버된 개수
• MISSEDRATIO : 커버되지 않은 비율(0~1)
• COVEREDRATIO (default) : 커버된 비율 (0~1)

*특정 클래스를 테스트 대상에서 제외하기 위해 아래와 같이 설정함

rule 2개

메이븐의 라이프 사이클

compile → test → package → install → deploy

Jacoco플러그인은 메이븐 라이프 사이클에 의해 동작, test phase 이후에 측정이 가능함 (package phase이후로 동작 가능)

 

 

 

+구글에서 사용하는 자바 코드 포맷 적용하기

인텔리제이 코드 포맷 변경하기 -> 구글에서 사용하는 코드 포맷 기준에 맞춰서 변경하기

google java style guide 사이트!

 

 

 

 

다음 글부터는.. 그래들을 사용한 강의를 들어볼게유....