[Clean Coding] 9. Unit Test

🖋️ 개요

Testing의 4단계

1. Unit Test : 유닛별 테스트
2. Integration Test : 유닛 테스트 통합 테스트
3. System Test : 개발 회사 내에서의 테스트
4. Acceptance Test : 고객의 테스트

이번 장에서는 Test의 기본 단위가 되는 Unit Test에 대해서 살펴볼 것이다.

📌 Unit Test

• Unit : 플고그램의 가장 작은 테스트가 가능한 작업 단위
  • Java : class
  • Java : method
  • C : function

• Unit Test : 개별 단위가 사용 가능 여부를 테스트하는 방법
  • 각각의 Unit은 최소한 하나의 test가 있어야하며
  • 조합이 있을수록 Good!
  • Production Code : 제품으로 내보낼 코드

간단한 예제와 함께 살펴보자
아래와 같은 코드가 있다고 해보자

public class Calc {
	public int add(int a, int b) {
    	return a + b;
    } //Unit
    
    public int subtract(int a, int b){
    	return a - b;
    } //U kt
}

Unit Test에서는 add(), subtract()를 독립적으로 테스트를 해서 잘 작동을 하는지 확인해야 한다

이에 따라 유닛 테스트는 아래와 같이 작성할 수 있다

public class TestCalc {
	public void testAdd() {
    	Calc calc = new Calc();
        if (calc.add(1, 2) == 3)
        	System.out.println("Success");
        else
        	System.out.println("Failure");
    }
    
    public void testSubtract() {
    	Calc calc = new Calc();
        if (calc.subtract(2,3) == -1)
        	System.out.println("Success");
        else 
        	System.out.println("Failure");
    }
}

여기서 Test case의 3가지 필수 요소를 확인할 수 있다

1. 입력이 무엇인가
2. 입력으로 돌려볼 코드가 무엇이고
3. 그 결과가 무엇이어야 하는가

🖋️ JUnit

• Java 프로그래밍 언어를 위한 유닛 테스팅 프레임워크
• 이러한 유닛 테스트 프레임워크를 xUnit이라 한다
  • Java : JUnit
  • C++ : CPPUnit
  • C : CUnit
  • Javascript : JSUnit
  • Python : PyUnit

• 지원
  • IDE : IntelliJ IDEA, Eclipse, NetBeans, Visual Studio Code (VS Code)
  • Build tools : Gradle, Maven, Ant
  • Console Launcher

• JUnit 5 = JUnit Jupiter + JUnit Platform
  • JUnit Jupiter : JUnit 5에서 테스트를 작성하기 위한 프로그래밍 모델
  • JUnit Platform : JVM에서 테스트 프레임워크를 실행하기 위한 기반

예시를 살펴보자

//static을 작성하지 않으면 쓸때마다 org.junit.~을 작성해줘야 한다
import static org.junit.jupiter.api.Assertions.*;
import org.junit.jupiter.api.*;

class MyTest {
	@BeforeAll
    static void initAll() { //모든 테스트 메서드가 실행되기 전에 실행
    }
    
    @BeforeEach
    void init() { //각 테스트 메서드가 실행되기 전 실행
   	}
    
    @Test
    void test() { //테스트 메서드 코드
    }
    
    @Test
    @Disabled("for demonstration purposes")
    void skippedTest() { //실행 x
    }
    
    @AfterEach
    void tearDown() { //각 테스트 메서드 실행 후 실행
    }
    
    @AfterAll
    static void tearDownAll() { // 모든 테스트가 끝난 후 한 번 수행
    }

• BeforeEach와 AfterEach는 optional이다
  • 각 테스트가 수행되기 전에 수행되어야 하는 코드가 있거나, 테스트 이후 수행해야 하는 코드가 있을 경우
• AfterAll은 TearDown 기법에 해당하는 것으로, 테스트 후 원래 상태로 되돌리기 위해 임시파일이나 record 작업이 필요할 수 있다

org.junit.jupiter.api.*를 import해야만 아래 annotation을 사용할 수 있다

• Annotations
  • @Test
  • @BeforeAll, @BeforeEach, @AfterEach, @AfterAll
  • @Disabled
  • @DisplayName
    • 화면에 찍어내고 싶은 것이 있을 경우
  • @Tag
    • 테스트를 필터링하기 위해 태그 선언
  • @Order
    • 순서를 보여주고 싶은 경우에 사용하지만 별로 바람직한 태그는 아님. 추천하지 않음

맨 처음에 살펴봤던 add, subtract 메서드의 유닛 테스트를 JUnit을 활용한다면 어떻게 작성할 수 있을까?

import static org.junit.jupiter.api.Assertions.*;
import org.junit.jupiter.api.*;

class CalcTest { // test class 선언
	@Test //이렇게 annotation을 작성해줘야 함
    void testAdd() {
    	Calc calc = new Calc();
        assertEquals(3, calc.add(1,2));
    }
    
    @Test
    void testSubtract() {
    	Calc calc = new Calc();
        assertEquals(2, calc.subtract(5,3));
    }
}

• org.junit.jupiter.api.Assertions 는 많은 라이브러리를 제공한다

Assertion methods

• assertEquals()
• assertTrue()
• assertFalse()
• assertNotNull()
• assertNull()
• assertArrayEquals()
• fail() : "이 자리에 오면 안됨.."처럼 그 자체로 fail. (ex. 루프 밖으로 나가면 안되는데 루프 밖으로 나간 경우)

compiling and executing your test

1. compile your program
   c:\javac Calc.java
2. compile yout test class
   C:>javac CalcTest.java
3. run the console laucher to execute JUnit tests
   C:>java -jar .\junit-platform-console-standalone-1.11.3jar -cp. -c CalcTest
   - cp: class path를 의미. .은 같은 위치에 있다는 것을 의미
   - 구동을 시작하는 놈이다. 지정된 아이를 수행시키도록 하는 것 (-c)

• JUnit은 fail한 테스트를 보고한다
  

• 그럼 Calc 클래스를 고치고 다시 테스트를 해야 하는 것이다
  

이러한 유닛 테스트를 모두 수기로 작성해야 할까?
자동으로 작성해주는 플랫폼이 존재한다
예시로 Agile methods, XP, test-driven development(TDD) 등이 있다

TDD에 더 살펴보자

🖋️ TDD (Test-Driven Development)

• 굉장히 짧은 개발 주기의 반복을 거치는 소프트웨어 개발 프로세스이다
  • 굉장히 구체적인 테스트 케이스에 대하여 요구사항을 제시
  • 이러한 테스트들이 패스되도록 코드가 개선된다

Test-driven development cycle

1. 테스트를 추가한다
2. 모든 테스트를 실행하고, 새로운 테스트가 실패하는지 본다
3. 코드를 작성한다
4. 모든 테스트를 실행한다
5. 코드를 리팩토링 한다

이 방법을 반복한다
기존의 코드를 망칠 수 있기 때문에 고쳐진 것이 있으면 기존의 것들이 다 테스트를 통과하는지 봐야한다

Three Laws of TDD

• First Law
  • 실제 기능을 구현하기 전에 반드시 해당 기능에 대한 유닛 테스트를 작성해야 한다
  • 코드부터 말고 테스트부터 작성해야 한다!
    
    
• Second Law
  • 유닛 테스트를 작성할 때, 실패를 확인할 수 있는 최소한의 코드만 작성해야 한다
    • 예: 단순히 테스트 코드가 컴파일되지 않는 것도 실패로 간주된다
  • 이 법칙은 테스트 코드가 너무 방대해지는 것을 방지하고, 하나씩 점진적으로 테스트를 추가하면서 문제를 정확히 파악하도록 돕는다
  • 조금씩 쌓아올려야 하며, 하나씩 아래서부터 테스트해온 것이 있기 때문에 에러가 난 지점을 쉽게 파악할 수 있다
    
    
• Third Law
  • 현재 작성한 유닛 테스트를 통과시키기에 충분한 최소한의 production code(기능 코드)만 작성해야 한다
  • 필요 이상의 코드를 작성하지 말고, 테스트 통과에 필요한 부분만 구현하라는 뜻이다
  • 이는 불필요한 코드를 방지하고, 코드를 테스트 가능하고 명확하게 유지한다

🖋️ Test 작성 방법

📌 Good Test

그냥 보여주기식의 테스트가 아니라, 좋은 테스트를 작성할 줄 알아야 한다

📍 Clean Test

테스트가 없는 것보다 더러운 테스트라도 있는게 더 낫다고 생각할 수 있다. 이것은 틀린 생각이다

why?

• production code가 발전하면서 테스트도 함께 변화해야 한다
• 오래된 더러운 테스트는 변경이 어려워지고, 점점 유지보수가 복잡해진다

Test Suite의 구성
1. 테스트 케이스
2. 테스트 시나리오
3. 테스트 데이터
4. 테스트 환경

이러한 test suite의 중요성

• test suite가 없다면 코드 변경이 제대로 작동하는지 보장할 수 없음
• test suite가 없으면 코드 변경이 두려워지고, 개발 속도와 품질에 부정적인 영향을 미치

결론 : 테스트 코드는 프로덕션 코드만큼 중요하다. 깨끗한 테스트 코드는 유지보수성과 신뢰성을 높여준다

🔻 clean test를 가능케 하는 것은

READABILITY 가독성이다!

what makes tests readable?

• clarity
• simplicity
• density of expression
  • 이것은 test에만 룰로, 코드를 밀도있게 작성해야하며 formatting을 꼭 안 따라도 된다. 반복적인 코드가 많이 생기기 때문

📍 Test는 -ilities를 가능하게 한다

테스트는 코드의 자신감을 제공한다

1. 테스트가 없는 경우

• 코드 변경 시 모든 변경 사항이 잠재적 버그가 될 수 있다
• 결과적으로 코드 변경이 두려워지고, 개발 속도가 느려진다

2. 유닛 테스트가 있는 경우

• 코드 변경에 대한 두려움을 없애준다
• 테스트 coverage가 높을수록, 변경에 대한 두려움이 적어진다
• 유연성, 지속 가능성, 재사용성을 높여준다!

🔻 Refactoring Procedure

✪ Dirty Test

문제

• 중복된 코드가 매우 많다 : ex. addPage9), assertSubString()
• 의도를 차근차근 설명했어야 했는데 디테일을 쏟아부었다 - StepDown rule 준수 x
  
  

✪ Refactored Test

UnitTest를 짤 때는 3단계로 나누어서 작성하는 것이 좋다

1. 테스트를 준비하는 단계
2. 테스트를 수행하는 단계
3. 테스트 결과를 확인하는 단계

개선된 코드에는 디테일도 사라지고, 중복도 제거가 되었다

🔻 Simple and Expressive Tests

테스트를 하다보면 동일한 과정을 확인해야 하는 경우가 있다

다음 예시를 살펴보자

@Test
public void turnOnLoTempAlarmAtThreashold() throws Exception {
	hw.setTemp(WAY_TOO_COLD);
    controller.tic();
    assertTrue(hw.heaterState());
    assertTrue(hw.blowerState());
    assertFalse(hw.coolerState());
    assertFalse(hw.hiTempAlarm());
    assertTrue(hw.loTempAlarm());
}

이 장비가 잘 작동하는지 보고싶은 것이고, 이를 위해서는 5개의 작업을 수행해야 하는 경우다

hardware=hw를 의미하며, 원래는 mental mapping을 피하라고 했었는데 테스트할 때는 반복이 워낙 많이 되기 때문에 허용한다

위 코드를 보면 어떠한가?
true, false만 계속 바뀌고 개수가 많아져 눈에 잘 들어오지 않는다

눈에 잘 들어오게 개선해보자

@Test
public void turnOnLoTempAlarmAtThreashold() throws Exception {
	wayTooCold();
    assertEquals("HBchL", hw.getState());
}

• H : Heater
• B : Blower
• C : Cooler
• H : HighTemp
• L : LowTemp

로 약어를 약속해서 사용했으며, true일 때만 대문자를 사용해서 다섯개의 결과를 하나의 string으로 반환하는 함수를 선언해서 사용했다

• 외워야 하지만, 중복된 표현이 나오니까 간략하게 표현하고자 한 것이다

import static org.junit.Assert.assertEquals;
import org.junit.Test;

public class TemperatureControlTest {

    // 가정: hw는 시스템 상태를 나타내는 객체
    private Hardware hw = new Hardware();

    @Test
    public void turnOnCoolerAndBlowerIfTooHot() throws Exception {
        tooHot(); // 너무 뜨거운 상태를 시뮬레이션
        assertEquals("hBChl", hw.getState());
    }

    @Test
    public void turnOnHeaterAndBlowerIfTooCold() throws Exception {
        tooCold(); // 너무 추운 상태를 시뮬레이션
        assertEquals("HBchl", hw.getState());
    }

    @Test
    public void turnOnHiTempAlarmAtThreshold() throws Exception {
        wayTooHot(); // 너무 뜨거운 경계값 상태를 시뮬레이션
        assertEquals("hBCHl", hw.getState());
    }

    @Test
    public void turnOnLoTempAlarmAtThreshold() throws Exception {
        wayTooCold(); // 너무 추운 경계값 상태를 시뮬레이션
        assertEquals("HBChl", hw.getState());
    }
    // 하드웨어 클래스 (테스트 대상 클래스의 더미 구현)
    class Hardware {
        private String state;

        public void setState(String state) {
            this.state = state;
        }

        public String getState() {
            return state;
        }
    }
}

📌 One Assert Per Test

하나의 테스트 함수에 하나의 assert만 작성하는 것을 지향하라고 한다

@Test
public void testBankAccount() {
    BankAccount account = new BankAccount();
    
    // 잔액 초기값 확인
    assertEquals(0, account.getBalance());
    
    // 입금 후 잔액 확인
    account.deposit(100);
    assertEquals(100, account.getBalance());
    
    // 출금 후 잔액 확인
    account.withdraw(50);
    assertEquals(50, account.getBalance());
}

하지만 이 코드의 경우, 여러 assertEquals를 포함하고 있어 코드가 긴 경우, 어떤 assert가 실패했는지 찾기가 어렵고, 가독성이 떨어질 수 있다

장점
테스트가 단일 결론을 내릴 수 있어 이해하기가 쉽고, 문제가 발생했을 때 어느 부분이 실패했는지 명확히 파악이 가능하다

단점
테스트를 너무 많이 분리하면 중복 코드가 많아질 수 있다

따라서 두 개의 테스트로 분리하고 given-when-then 패턴을 활용한다!

@Test
public void testGetPageHierarchyAsXml() throws Exception {
    givenPages("PageOne", "PageOne.ChildOne", "PageTwo");
    
    whenRequestIsIssued("root", "type:pages");
    
    thenResponseShouldBeXML();
}

@Test
public void testGetPageHierarchyHasRightTags() throws Exception {
    givenPages("PageOne", "PageOne.ChildOne", "PageTwo");
    
    whenRequestIsIssued("root", "type:pages");
    
    thenResponseShouldContain(
        "<name>PageOne</name>", 
        "<name>ChildOne</name>", 
        "<name>PageTwo</name>"
    );
}

• 단일 assert 규칙은 지켜야 할 "좋은 지침"이지만, 상황에 따라 유연하게 적용 가능.
• 테스트 내 assert 개수를 최소화하는 것이 중요하지만, 필요한 경우 여러 assert를 사용하는 것도 괜찮다.

🔻 Single Concept per Test 예시

가장 좋은 룰은, 테스트당 하나를 검증하고자 한다면 assert문이 여러번 나와도 ok!

위 코드는 아래처럼 개선할 수 있다
의도가 잘 드러나는 이름으로 수정하여 테스트 메소드를 task마다 각각 만들어준다

• 문제는 여러 개의 assert가 아니다. 진짜 문제는 테스트 함수가 여러 개념을 동시에 테스트하는 경우 발생한다
• 하나의 개념만 테스트를 해야 테스트가 단순하고 명확하며, 실패 시 원인을 빠르게 파악할 수 있다
• 각 개념의 대해 최소한의 assert를 사용하고, 테스트 함수 하나당 하나의 개념만 포함하도록 설계한다
• 그러면 테스트의 가독성과 유지보수성이 향상될 것이다!

🖋️ [F.I.R.S.T] 테스트를 하면 지켜야할 규칙

📍 Fast

테스트는 빠르게 작동되어야 한다
느리면 여러 번 돌려볼 수 없기 때문!

📍 Independent

독립성을 보장해야한다. 필요한 것만 수행될 수 있도록!
테스트가 완료가 되면 원상태로 되돌리는 작업이 반드시 필요하다! (TearDown)

📍 Repeatable

테스트는 특수한 환경이 아니라, 소프트웨어를 설치할 모든 환경에서 작동이 가능해야 한다. 범용성 중요!

📍 Self-Validating

유닛 테스트 엔터를 누르고 나서부터는 중간에 사용자에게 input을 받거나 결과를 파일로 저장해서 사용자보고 확인해보라는 액션이 나오면 안된다

모든게 다 자동화 되어야 한다

📍 Timely

테스트를 작성하는 시점이 중요하다!
TDD! test lag가 발생하면 코드가 앞서가게 된다

코딩을 하기 전에 테스트를 먼저 작성을 하던가, 테스트가 코딩을 따라가도록 반드시 설정을 해야한다

🔻 나쁜 Unit Test 케이스의 7개 증상

1. 테스트는 패스하지만 실제 featrue는 테스팅하지 않는 것
2. 관련없는 것들을 테스팅 하는 것
3. assertion에서 다수의 것을 테스팅하는 것
4. 에러를 삼켜버리는 테스트
5. 빠르게 진행하지 않고, setup이 느려서 시간이 많이 소요되는 테스트
6. 개발자 자신의 pc에서만 작동하는 테스트
7. 결과를 파일로 내뿜어서 사용자가 직접 클릭해서 보게 하는 테스트

결론

가독성 중요!
유연성, 지속가능성, 재사용성!