JUnit

3. JUnit의 특징

1997년 에리히 감마와 켄트 백은 스몰토크용 유닛 테스트 프레임워크인 SUnit을 기반으로 JUnit을 개발하였다.^[1] JUnit은 아파치 앤트나 이클립스 플러그인과 함께 사용할 수 있으며, 단독으로도 동작 가능하다.^[1]

JUnit은 익스트림 프로그래밍과 같은 애자일 소프트웨어 개발 방법론에서 중요하게 다루어지며, 자바 시스템 개발에서 필수적인 요소로 자리 잡았다.^[1] 자바 이외의 언어용으로는 xUnit이 있다.^[1]

JUnit의 주요 특징은 다음과 같다:^[1]

• 테스트 코드를 한 번 작성하면 빠르게 테스트할 수 있다.
• 테스트 코드를 표본으로 활용하여 버그 수정을 쉽게 할 수 있다.
• 테스트 코드를 통해 사양을 한눈에 파악할 수 있다.
• 누구나 동일한 테스트를 수행할 수 있다.
• 독자적인 테스트 코드 작성의 수고를 덜 수 있다.

4. JUnit의 문제점

JUnit은 사양 변경 시마다 테스트 코드를 다시 만들어야 하는 문제점이 있다.^[1] 이클립스 등의 통합 개발 환경(IDE)을 사용하면 테스트 코드 재작성으로 인한 수고를 줄일 수 있다.^[1] 익스트림 프로그래밍(XP) 등의 테스트 주도 개발에서는 테스트 코드 자체가 사양이라는 생각에 기반하기 때문에 이 문제가 해소되는 경우가 있다.^[1]

또한, 테스트 코드 작성에 시간이 걸린다는 문제점도 있다.^[1] 이클립스 등의 IDE를 사용하여 테스트 코드 작성을 빠르게 할 수도 있다.^[1] "테스트는 기능 테스트이며, 내부 로직의 확인이 아니다"라는 생각에 기반하면 이 문제가 해소되는 경우가 있다.^[1]

5. JUnit 4의 새로운 기능

JUnit 테스트 픽스처(test fixture)는 자바 객체이다. 구 버전의 JUnit에서는 픽스처가 `junit.framework.TestCase`를 상속해야 했으나, JUnit 4에서는 더 이상 그럴 필요가 없다.^[14] 테스트 메소드는 `@Test` 어노테이션을 통해 어노테이트해야 한다.^[15]

JUnit4는 Java SE 5부터 어노테이션을 사용할 수 있게 되어, 기존의 명명 규칙에 얽매이지 않게 되어 더욱 사용하기 편리해졌다. 과거에는 테스트 클래스명은 `Test`로 끝나야 했고, 테스트하고 싶은 메서드를 테스트하는 메서드명에는 `test` 접두사를 붙여야 했다. JUnit4부터는, `TestCase#setUp()`, `TestCase#tearDown()` 메서드를 오버라이드할 필요가 없어지고, 대신에, `setUp()`에 해당하는 메서드에는 `@Before` 어노테이션을 붙이고, `tearDown()`에 해당하는 메서드에는 `@After` 어노테이션을 붙이는 것만으로 충분해졌다. 게다가, 메서드에 `@BeforeClass`, `@AfterClass` 어노테이션을 붙임으로써, 테스트 클래스 실행 전과 실행 후에 실행하고 싶은 메서드를 만들 수도 있게 되었다.

5. 1. JUnit 4에서 사용 가능한 어노테이션

• `@Test` - 해당 메서드가 테스트 메서드임을 나타낸다. 이 메서드에 테스트를 작성한다. 기존 JUnit에서 메서드 이름이 `test`로 시작하는 메서드와 동일하다.
• `@Before` - 이 어노테이션이 붙은 메서드는 `@Test` 어노테이션이 붙은 메서드를 실행할 때마다 사전에 실행됨을 의미한다. JUnit 4 이전의 `setup()` 메서드와 동일하다.
• `@After` - 이 어노테이션이 붙은 메서드는 `@Test` 어노테이션이 붙은 메서드를 실행할 때마다 반드시 나중에 실행됨을 의미한다. JUnit 4 이전의 `tearDown()` 메서드와 동일하다.
• `@BeforeClass` - 이 어노테이션이 붙은 메서드는 해당 테스트 클래스를 호출하기 전에 실행된다.
• `@AfterClass` - 이 어노테이션이 붙은 메서드는 해당 테스트 클래스를 호출한 후에 실행된다.

6. JUnit 5의 새로운 기능

JUnit 5는 `@Test` 어노테이션을 사용하여 테스트 메서드를 표시한다.^[14] 또한, `@BeforeAll`, `@BeforeEach`, `@AfterEach`, `@AfterAll` 어노테이션을 통해 테스트 실행 전후에 필요한 설정을 할 수 있다.^[15]

```java

import org.junit.jupiter.api.*;

public class FoobarTest {

@BeforeAll

public static void setUpClass() throws Exception {

// 모든 테스트 메소드 실행 전에 한 번 실행

}

@BeforeEach

public void setUp() throws Exception {

// 각 테스트 메소드 실행 전에 실행

}

@Test

public void oneThing() {

// 한 가지 기능 테스트

}

@Test

public void anotherThing() {

// 다른 기능 테스트

}

@Test

public void somethingElse() {

// 또 다른 기능 테스트

}

@AfterEach

public void tearDown() throws Exception {

// 각 테스트 메소드 실행 후에 실행

}

@AfterAll

public static void tearDownClass() throws Exception {

// 모든 테스트 메소드 실행 후에 한 번 실행

}

}

6. 1. JUnit 5의 확장 모델

7. JUnit 테스트 픽스처

JUnit 테스트 픽스처(test fixture)는 자바 객체이다. 구 버전의 JUnit의 경우 픽스처는 `junit.framework.TestCase`로부터 상속해야 했으나 JUnit 4의 새 테스트는 이렇게 하지 않는다.<sup>[14]</sup> 테스트 메소드는 `@Test` 어노테이션을 통해 어노테이트해야 한다.<sup>[15]</sup>

JUnit의 모든 테스트 클래스는 일반적으로 여러 개의 테스트 케이스를 가지며, 이러한 테스트 케이스는 테스트 생명주기를 따른다. 전체 JUnit 생명주기는 다음 세 가지 주요 단계로 구성된다.

# 설정 단계 - 테스트 인프라를 준비하는 단계이다. 두 가지 수준의 설정이 가능하다.

## 클래스 수준 설정: 데이터베이스 연결과 같이 계산 비용이 많이 드는 객체를 생성하고 재사용하며 부작용을 최소화한다. `@BeforeAll` 어노테이션을 사용하여 구현한다.

## 각 테스트 케이스 실행 전 설정: `@BeforeEach` 어노테이션을 사용한다.

# 테스트 실행 - 테스트를 실행하고 결과를 확인하는 단계이다. 테스트 결과는 테스트 성공 여부를 나타낸다. `@Test` 어노테이션이 사용된다.

# 정리 단계 - 모든 테스트 실행이 완료된 후 시스템은 정리를 수행해야 할 수 있다. 클래스 수준 설정과 유사하게 해당 클래스 수준 정리도 있다.

## 클래스 수준 정리: `@AfterAll` 어노테이션은 클래스 수준 정리를 지원하는 데 사용된다.

## 테스트 실행 후 정리: `@AfterEach` 어노테이션을 사용하여 수행할 수 있다.

JUnit 테스트 픽스처는 자바 객체이다. 테스트 메서드는 `@Test` 어노테이션으로 주석 처리해야 한다. 상황에 따라<sup>[4]</sup> 각 (또는 모든) 테스트 메서드 전(또는 후)에 실행할 메서드를 `@BeforeEach` (또는 `@AfterEach`) 및 `@BeforeAll` (또는 `@AfterAll`) 어노테이션으로 정의할 수도 있다.<sup>[5]</sup>

```java

import org.junit.jupiter.api.*;

class FoobarTests {

@BeforeAll

static void setUpClass() throws Exception {

// 첫 번째 테스트 메서드 전에 실행되는 코드

}

@BeforeEach

void setUp() throws Exception {

// 각 테스트 전에 실행되는 코드

}

@Test

void oneThing() {

// 한 가지를 테스트하는 코드

}

@Test

void anotherThing() {

// 다른 것을 테스트하는 코드

}

@Test

void somethingElse() {

// 또 다른 것을 테스트하는 코드

}

@AfterEach

void tearDown() throws Exception {

// 각 테스트 후에 실행되는 코드

}

@AfterAll

static void tearDownClass() throws Exception {

// 마지막 테스트 메서드 후에 실행되는 코드

}

}

8. 다른 도구와의 통합

JUnit 5는 빌드 도구, 통합 개발 환경(IDE), 지속적 통합(CI) 도구 등 다양한 도구와 통합된다.<sup>[1]</sup> 아파치 앤트나 이클립스 플러그인에서도 사용할 수 있다. 익스트림 프로그래밍과 같은 애자일 소프트웨어 개발 방법론에서는 테스트를 중시하며 자주 소개된다. 자바의 초기부터 테스트 실행 환경을 제공해 왔으며, 자바를 사용하는 시스템 개발에서는 필수적인 요소가 되었다.

자바 이외의 언어용으로는 xUnit이 존재한다.

8. 1. 빌드 도구

• '''아파치 앤트(Apache Ant)''': 앤트(Ant)라고도 불리는 이 도구는 가장 다재다능한 빌드 도구 중 하나이며, 위에 언급된 세 가지 빌드 도구 중에서 가장 오랜 역사를 가지고 있다.<sup>[3]</sup> 앤트는 프로젝트 실행에 필요한 작업을 구성하는 데 사용되는 `build.xml` 파일을 중심으로 한다.<sup>[3]</sup> 앤트는 또한 의존성 해결을 돕는 아파치 아이비(Apache Ivy)라는 확장 기능을 가지고 있다. 프로젝트 의존성은 `ivy.xml` 파일에 선언할 수 있다. 앤트는 `ivy.xml` 파일에 대한 자바 코드 커버리지 도구 (JaCoCo)를 구성하여 JUnit 5와 통합할 수 있다.<sup>[3]</sup> 그런 다음 `ivy.xml`은 `java-platform-console` 및 `junit-platform-runner` 종속성을 사용하여 JUnit 5와 통합하도록 구성할 수 있다.<sup>[4]</sup>
• '''아파치 메이븐(Apache Maven)''': Ant와 달리, 메이븐(Apache Maven)은 빌드 프로세스에 표준화되고 통합된 접근 방식을 사용한다. 메이븐은 종속성을 관리하기 위해 "설정보다 관례"라는 패러다임을 따른다. 자바 소스 코드("src")는 `src/main/java` 디렉토리에서 찾을 수 있으며, 테스트 파일은 `src/test/java` 디렉토리에서 찾을 수 있다. 메이븐은 모든 자바 프로젝트에 사용할 수 있다. 메이븐은 프로젝트 객체 모델 (POM)을 사용하며, 이는 프로젝트의 빌드 단계를 구성하는 XML 기반 접근 방식이다. `pom.xml` 빌드 파일을 사용하는 최소한의 메이븐은 종속성 목록과 고유한 프로젝트 식별자를 포함해야 한다. 메이븐이 작동하려면 빌드 경로에서 사용할 수 있어야 한다. 메이븐은 JUnit 5 테스트를 위한 즉시 사용 가능한 기능을 지원하는 `jacoco-maven-plugin` 플러그인을 사용하여 JUnit 5와 통합할 수 있다. 이러한 작업을 수행하기 위해 서로 다른 메이븐 골(goal)을 지정할 수 있다.
• '''Gradle''': Gradle은 이전 빌드 도구인 Ant와 Maven의 많은 개념을 차용한 빌드 도구이다.<sup>[5]</sup> Gradle은 프로젝트 빌드에 필요한 단계를 선언하기 위해 `build.gradle` 파일을 사용한다.<sup>[5]</sup> XML 기반인 Ant와 Maven과 달리 Gradle은 Java 기반 프로그래밍 언어인 아파치 Groovy를 사용해야 한다.<sup>[5]</sup> Ant와 Maven과 달리 Gradle은 XML을 사용할 필요가 없다.<sup>[5]</sup> Gradle은 여전히 Maven의 "구성보다 관례" 접근 방식을 따르며, `src/main/java` 및 `src/test/java` 디렉토리에 대해 동일한 구조를 따른다.<sup>[5]</sup> Gradle은 빌드 파일에서 JUnit 5 팀이 제공하는 junit-platform 플러그인과 함께 `jacoco` 플러그인을 구성하여 JUnit 5와 통합할 수 있다.<sup>[6]</sup>

9. 다른 프로그래밍 언어 지원

10. JUnit 파생 도구 및 관련 도구

1997년 스몰토크용 유닛 테스트 프레임워크인 SUnit을 기반으로 에리히 감마와 SUnit 개발자인 켄트 백을 중심으로 개발되었다.<sup>[10]</sup>

자바 이외의 언어용으로는 xUnit이 존재한다. JUnit에서 파생된 도구는 다음과 같다.

• TestNG - 'Test the Next Generation'의 약자로 여겨진다. Java SE 5부터 추가된 애노테이션을 이용하여 클래스나 메서드에 Test/test라고 명명할 필요가 없어졌다. JUnit4에서는 마찬가지로 명명 규칙이 완화되었다. 그 외에도 JUnit4에서는 사용할 수 없는 기능이 추가되었다.
• JxUnit - JUnit은 private 메서드를 테스트할 수 없지만 JxUnit은 테스트가 가능하다. 내부적으로 리플렉션을 이용한다.
• Jakarta Cactus - 서블릿의 단위 테스트뿐만 아니라 통합 테스트를 실행할 수 있다.
• Mock 객체 - 테스트용으로 객체를 위장한다.
• djUnit - JUnit의 테스트를 그대로 실행할 수 있으며, 커버리지 보고서 출력이 가능하다.

참조

<sub>[1]</sub> 웹사이트 JUnit Releases https://github.com/j[...] 2023-07-23
<sub>[2]</sub> 웹사이트 Change license to EPL v2.0 https://github.com/j[...] 2017-09-07
<sub>[3]</sub> 웹사이트 We Analyzed 30,000 GitHub Projects – Here Are The Top 100 Libraries in Java, JS and Ruby http://www.takipiblo[...] 2014-02-09
<sub>[4]</sub> 웹사이트 Expensive Setup Smell http://c2.com/cgi/wi[...] C2 Wiki 2011-11-28
<sub>[5]</sub> 웹사이트 Writing Tests https://junit.org/ju[...] 2021-02-04
<sub>[6]</sub> 웹사이트 bliki: Xunit https://martinfowler[...] 2022-03-07
<sub>[7]</sub> 웹사이트 JUnit https://mvnrepositor[...] 2021-10-29
<sub>[8]</sub> 웹사이트 JUnit Cookbook http://junit.sourcef[...] junit.sourceforge.net 2011-05-21
<sub>[9]</sub> 웹사이트 Migrating from JUnit 3 to JUnit 4: Nothing But Good News https://objectcomput[...] Object Computing, Inc. 2007-08
<sub>[10]</sub> 문서 コード品質を追求する: JUnit 4 対 TestNG 大規模なテストでは TestNG のほうが優れたフレームワークになる理由 http://www.ibm.com/d[...]
<sub>[11]</sub> 웹인용 JUnit Releases https://github.com/j[...] 2022-09-22
<sub>[12]</sub> 웹인용 Relicense JUnit from CPL to EPL https://github.com/j[...] Philippe Marschall 2013-05-18
<sub>[13]</sub> 웹인용 We Analyzed 30,000 GitHub Projects – Here Are The Top 100 Libraries in Java, JS and Ruby http://www.takipiblo[...] 2019-04-17
<sub>[14]</sub> 웹인용 JUnit Cookbook http://junit.sourcef[...] junit.sourceforge.net
<sub>[15]</sub> 웹인용 Expensive Setup Smell http://c2.com/cgi/wi[...] C2 Wiki