Skip to content
This repository has been archived by the owner on Aug 13, 2022. It is now read-only.

JUnit5를 활용한 효과적인 테스트 코드 작성 #106

Open
hanwix2 opened this issue May 18, 2021 · 2 comments
Open

JUnit5를 활용한 효과적인 테스트 코드 작성 #106

hanwix2 opened this issue May 18, 2021 · 2 comments
Assignees

Comments

@hanwix2
Copy link
Collaborator

hanwix2 commented May 18, 2021

JUnit 5의 구조

  • JUnit5 Platform: 테스트를 실행해주는 런처 제공. Platform위에 jupiter와 vintage를 올릴 수 있는 구조
    • Jupiter: JUnit5를 지원하는 TestEngine API 구현체
    • Vintage: JUnit4,3를 지원하는 TestEngine API 구현체

JUnit5 Annotations

  • @test
    • 테스트 메소드라는 것을 나타냄
    • JUnit4 와는 다르게 어떠한 속성도 선언하지 않는다.
  • @BeforeAll
  • @afterall
  • @beforeeach
  • @AfterEach
  • @disabled
    • 테스트를 하고 싶지 않는 클래스나 메소드에 붙이는 어노테이션
    • 주석 처리를 하지 않고도 테스트 수행을 막아준다.
  • @DisplayName
    • 어떤 테스트인지 쉽게 표현할 수 있도록 해주는 어노테이션
    • 공백, 이모지, 특수문자 등 지원
  • @RepeatedTest
    • 특정 테스트를 반복하고 싶을 때 사용
    • 반복 횟수와 반복 테스트 이름 설정 가능
    • 성능적인 이슈 확인 시 사용
  • @ParameterizedTest
    • 반복적으로 수행해야 할 테스트에 데이터를 정의
    • 테스트에 여러 다른 매개변수를 대입
    • 반복문을 사용하는 것보다 가독성 향상 & 테스트 성격, 목적을 잘 드러냄
  • @nested
    • 테스트 클래스 안에서 내부 클래스를 정의하여 테스트를 계층화 할 때 사용
    • 내부 클래스는 부모 클래스의 멤버 필드에 접근 가능
    • Before / After와 같은 테스트 생명주기에 연관된 메소드들도 계층에 맞춰 동작

JUnit5 Assertions

테스트 케이스의 수행 결과를 판별하는 메소드

  • assertAll(executables...)
    • 매개변수로 받는 모든 테스트 코드를 한 번에 실행
    • 오류가 나도 끝까지 실행한 뒤 한 번에 모아서 출력
  • assertThrows(expectedType, executable)
    • 예외 발생을 확인하는 테스트
    • executable의 로직이 실행되는 도중 expectedType의 에러를 발생시키는지 확인
  • assertDoesNotThrow
    • 예외가 던져지지 않음을 검증
  • assertTimeOut(duration, executable)
    • 특정 시간 안에 실행이 완료되는지 확인

JUnit5 Assumption

전제문에 true라면 실행, false라면 종료
CI 같이 특정 환경에서만 테스트를 진행하는 경우에 사용 가능

  • assumeTrue:
    • 파라미터의 값이 True일 때만 테스트 수행
    • 파라미터가 False로 테스트가 수행되지 않으면 테스트는 실패한 것이 아닌 @disabled 구문과 동일하게 처리
  • assumimgThat:
    • 파라미터가 True일 때만 함께 전달된 코드블럭(함수형 파라미터) 실행

이외 기초적인 기능 및 이전 버전의 기능은 생략


ETC

BDD(Behavior-Driven Development. 행위 주도 개발)

  • Given-When-Then Pattern
    • 준비, 실행, 검증 세 부분으로 나누어 테스트 코드를 작성하는 방법
      • Given: 테스트에 사용하는 변수, 입력 값, 객체 등을 정의하는 과정
      • When: 테스트를 할 모듈을 실제로 실행하는 과정
      • Then: 실행된 테스트를 검증하는 과정
  • BDDMockito
    • Mockito를 상속한 테스트 프레임워크
    • Mockito와 기능과 사용법은 비슷하지만 BDD 기반으로 테스트 코드를 작성할 때 시나리오에 맞는 메소드 명을 제공함으로 가독성 향상
    • Example:
      1. Given 과정에서 Mockito의 when() 메소드를 BDDMockito의 given()으로 대체
      2. Then 과정에서 Mockito의 verify() 메소드를 BDDMockito의 then().should()로 대체

@hanwix2
Copy link
Collaborator Author

hanwix2 commented May 18, 2021

특별히 @Nested 를 사용하여 테스트를 특징이 비슷한 것 끼리 그룹화 한다면 가독성이 향상될 것으로 기대합니다.

@tlsgkr7416
Copy link
Contributor

tlsgkr7416 commented May 18, 2021

@nested를 사용하면 도움이 많이 될 거 같네요. 프로젝트를 진행하면서 특징이 비슷한 테스트 코드의 함수명들을 지어줄 경우 중복되는 단어나 문장이 들어갈 때가 많아서 가독성에 좋지 않은 경험이 있었는데요. 이때 @nested를 사용한다면 도움이 많이 될 거 같습니다.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants