[자바 코딩의 기술] 6장 : 올바르게 드러내기

6.1 Given-When-Then으로 테스트 구조화

JUnit은 자바 클래스 라이브러리에는 속하지 않지만 자바에서 단위 테스트 작성하는 사실상의 표준이다.

메서드에 @Test만 추가하면 JUnit이 알아서 테스트로 실행한다.

문제 코드

    @Test
    void setPlanetarySpeedIs7667() {
        CruiseControl cruiseControl = new CruiseControl();
        cruiseControl.setPreset(SpeedPreset.PLANETARY_SPEED);
        Assertions.assertTrue(7667 == cruiseControl.getTargetSpeedKmh());
    }

위 테스트는 올바르게 작동한다. 하지만 우리는 좀 더 코드를 구조화하여 읽기 쉽게 바꿀 수도 있다.

 

given, when, then 구조를 이요하여 테스트 코드를 작성해보자.

    void otherTest() {
        // given
        CruiseControl cruiseControl = new CruiseControl();

        // when
        cruiseControl.setPreset(SpeedPreset.PLANETARY_SPEED);

        // then
        Assertions.assertTrue(7667 == cruiseControl.getTargetSpeedKmh());
    }

• given : 테스트하려는 기능을 실행하기 위한 전제 조건
• when : 실제로 테스트하려는 연산을 수행
• then : when에서 수행한 결과가 실제로 기대했던 결과인지 검증 (assertion)

이렇게 세 가지로 테스트를 구조화하면 각 부분이 더 명확히 드러난다.

 

6.2 의미 있는 어서션 사용하기

'assertTrue()' 말고 'assertEquals()' 를 사용하자.

Assertions.assertTrue(7667 == cruiseControl.getTargetSpeedKmh());

assertTrue 사용 시 성공 시에는 문제없이 작동하지만

실패 시 'java.lang.AssertionError'라는 스택추적을 받는데 여기에 주어진 정보는 (실패한 클래스, 실패한 줄 번호)말고 어떠한 메시지도 없다. 따라서, 어떤 어서션이 왜 실패했는지 알 수 없다..

 

그렇다면 더 자세한 오류 메시지를 얻기 위해 어서션에 정보를 넣으려면 어떻게 해야할까??

Assertions.assertEquals(7667, cruiseControl.getTargetSpeedKmh());

assertEquals를 사용하면 JUnit 테스트 실패 시 훨씬 나은 오류 메시지를 제공한다. --> ex) expected <7667> but was <1337>

 

이외에도 많은 assertion이 있다. 각 테스트의 상황에 맞춰 가장 적합한 어서션을 선택하는 것이 중요하다.

 

6.3 실제 값보다 기대 값을 먼저 보이기

('기대', '실제')

assertionEquals() 사용시 주의할 점!!

assertEquals(첫번째 인자 = 기댓값, 두번째 인자 = 실제 값)

 

첫번째 인자는 기댓값, 두번째 인자는 실제값으로 들어가는 인자 순서를 꼭 지켜야만 한다.

 

이러한 인자의 순서를 잘못 입력하게 되면 메시지를 오인하게 되고 이는 잘못된 디버깅으로 더욱 깊은 오류로 빠지게 될 수 있다.

이는 매우 사소하지만 중요한 문제이다.

 

6.4 합당한 허용값 사용하기

    @Test
    void testFilling() {
        OxygenTank tank = OxygenTank.withCapacity(100);

        tank.fill(5.8);
        tank.fill(5.6);

        Assertions.assertEquals(0.114, tank.getStatus());
    }

위 코드는 0.114와 탱크의 상태값을 비교한다. 하지만 이 테스트는 예상치 못하게 실패할 확률이 있는 코드이다.

 

왜냐면 부동소수점 연산을 표현할 수 있는 비트 수는 제한적이기 때문에 아주아주 작은 오차는 용인하고 근사값으로 바뀌게 된다.

 

그렇기 때문에 기대했던 값과 실제 값의 근사 값이 다를 수 있다.

 

따라서, 부동소수점 연산을 테스트할 때는 반드시 소숫점 자릿수를 명시해야만 한다.

개선 코드 (3번째 인자로 몇번째 자리까지 차이를 같은 값으로 볼 것인지 인자를 넘김)

    static final double TOLERANCE = 0.00001;
    
    @Test
    void testFilling() {
        OxygenTank tank = OxygenTank.withCapacity(100);

        tank.fill(5.8);
        tank.fill(5.6);

        Assertions.assertEquals(0.114, tank.getStatus(), TOLERANCE);
    }

6.5 예외 처리는 JUnit에 맡기기

문제 코드

class LogbookTest {

    @Test
    void readLogbook() {
        Logbook logbook = new Logbook();

        try {
            List<String> entries = logbook.readAllEntries();
            Assertions.assertEquals(13, entries.size());
        } catch (IOException e) {
            Assertions.fail(e.getMessage());
        }
    }

    @Test
    void readLogbookFail() {
        Logbook logbook = new Logbook();

        try {
            logbook.readAllEntries();
            Assertions.fail("read should fail");
        } catch (IOException ignored) {}
    }
}

두 테스트 모두 정상 실행되지만 단점을 가진다.

 

첫번째 테스트는 '원인사슬'이 깨진다. 메시지만 제공할 뿐 전체 예외를 스택 추적으로 제공하지 않기 때문이다.

두번째 테스트는 예외가 일어나길 기대하지만 코드로는 왜 예외가 일어나야만 하는지 알 수 없다...

 

개선 코드

class LogbookTest {

    @Test
    void readLogbook() throws IOException {
        Logbook logbook = new Logbook();

        List<String> entries = logbook.readAllEntries();

        Assertions.assertEquals(13, entries.size());
    }

    @Test
    void readLogbookFail() {
        Logbook logbook = new Logbook();

        Executable when = () -> logbook.readAllEntries();

        Assertions.assertThrows(IOException.class, when);
    }
}

 

테스트에서 예외를 명시적으로 추가하지 말고 그냥 JUnit이 알아서 하게 놔두면 된다.

 

첫번째 테스트에서 try와 fail을 빼도 '원인 사슬'이 깨지지 않으면서 전체 스택 추적도 제공한다.

두번째 테스트에서는 try-catch 대신 assertThrows를 이용하여 인자로 예외가 생기길 바라는 메서드를 전달하고 어떤 종류의 예외를 바라

는지도 명시한다.

6.6 테스트 설명하기

좋은 코드

class OxygenTankTest {
    static final double PERMILLE = 0.001;

    @Test
    @DisplayName("Expect 44% after filling 22l in an empty 50l tank")
    @Disabled("We don't have small tanks anymore! TODO: Adapt for big tanks")
    void fillTank() {
        OxygenTank smallTank = OxygenTank.withCapacity(50);

        smallTank.fill(22);

        Assertions.assertEquals(0.44, smallTank.getStatus(), PERMILLE);
    }

    @Test
    @DisplayName("Fail if fill level > tank capacity")
    void failOverfillTank() {
        OxygenTank bigTank = OxygenTank.withCapacity(10_000);
        bigTank.fill(5344.0);

        Executable when = () -> bigTank.fill(6000);

        Assertions.assertThrows(IllegalArgumentException.class, when);
    }
}

위 코드는 Given-When-Then 구조, 합당한 허용값, JUnit에 예외처리를 맡기는 행동을 하며 올바르게 작동하고 있다.

 

거기에 테스트에 대한 '이름'과 '설명서'가 추가되어 한층 더 좋은 테스트 코드이다.

 

테스트에 실패했을 때 좋은 메시지를 보내기 위해선 좋은 메서드명과 테스트 설명이 필요하다.

testfill2() 대신 failOverfillTank() 처럼 의도를 들어내는 메서드 명을 사용해야 한다. (오류시 테스트명 의미있는 테스트 명 노출)

@DisplayName("테스트 설명") 을 사용하면 메서드명을 바꾸지 않고도 훌륭한 테스트 설명을 추가할 수 있다.

또한, @DisplayName을 이용해 비활성화한 테스트에 대해 왜 비활성화했는지 이유도 적을 수 있다.

6.7 독립형 테스트 사용하기

문제점

@BeforeEach 와 @BeforeAll 표기를 쓸 때 발생할 수 있는 문제점이 있다.

두 표기는 테스트의 given에 해당하는 필요한 공통 설정 코드를 추출해 한번만 작성할 수 있게 해준다.

 

하지만 이는 테스트 전체를 이해하기 어려워지는 현상이 발생한다.

 

클래스 전체를 읽지 않거나 테스트가 매우 많은 상황을 가정해보자.

이때 만약 테스트가 실패하게되면 실패한 테스트 메서드로 갈테니 given 부분이 어디인지 쉽게 찾을 수 없다. (여러 설정 메서드가 클래스 계층 구조에 퍼져있는 복잡한 코드 일 때..)

 

개선 코드

class OxygenTankTest {
    static OxygenTank createHalfFilledTank() {
        OxygenTank tank = OxygenTank.withCapacity(10_000);
        tank.fill(5_000);
        return tank;
    }

    @Test
    void depressurizingEmptiesTank() {
        OxygenTank tank = createHalfFilledTank();

        tank.depressurize();

        Assertions.assertTrue(tank.isEmpty());
    }

    @Test
    void completelyFillTankMustBeFull() {
        OxygenTank tank = createHalfFilledTank();

        tank.fillUp();

        Assertions.assertTrue(tank.isFull());
    }
}

given, when, then 부붐을 하나의 테스트 안에서 바로 연결하면 '독립적인 테스트'가 된다.

 

createHalfFilledTank()처럼 static 메서드를 사용하면 중복 코드가 아니면서 각 테스트를 독립적으로 이해할 수 있게 된다.

모든 종속성을 명시적으로 표시했으므로 프로그래머는 코드를 이해하기 쉬워지고 오류도 좀 더 쉽게 찾을 수 있다.

 

@BeforeEach 와 @BeforeAll 표기는 암묵적 종속성을 만들어내므로 가능하면 사용하지 말자. (대신 static 공용 메서드 사용)

6.8 테스트 매개 변수화

여러 다양한 입력 매개변수로 테스트해야 할 때가 있다.

class DistanceConversionTest {

    @Test
    void testConversionRoundTrip() {
        assertRoundTrip(1);
        assertRoundTrip(1_000);
        assertRoundTrip(9_999_999);
    }

    private void assertRoundTrip(int kilometers) {
        Distance expectedDistance = new Distance(
                DistanceUnit.KILOMETERS,
                kilometers
        );

        Distance actualDistance = expectedDistance
                .convertTo(DistanceUnit.MILES)
                .convertTo(DistanceUnit.KILOMETERS);

        Assertions.assertEquals(expectedDistance, actualDistance);
    }
}

모든 검증이 필요한 경우의 수에 대해 파라미터 값을 따로 넣어줘야 한다.

만약, 파라미터 '1'에서 예외가 발생하면 파라미터 '1000'은 검증도 못해보게 된다..

 

이 문제를 해결해야 한다.

개선 코드

class DistanceConversionTest {

    @ParameterizedTest(name = "#{index}: {0}km == {0}km->mi->km")
    @ValueSource(ints = {1, 1_000, 9_999_999})
    void testConversionRoundTrip(int kilometers) {
        Distance expectedDistance = new Distance(
                DistanceUnit.KILOMETERS,
                kilometers
        );

        Distance actualDistance = expectedDistance
                .convertTo(DistanceUnit.MILES)
                .convertTo(DistanceUnit.KILOMETERS);

        Assertions.assertEquals(expectedDistance, actualDistance);
    }
}

@ParameterizedTest(name = "#{index}: {0}km == {0}km->mi->km")

@ValueSource(ints = {1, 1_000, 9_999_999})

표기로 테스트를 매개변수화 할 수 있다. 즉, '매개변수' 와 '테스트코드'를 분리하는 것이다.

 

실행해보면 JUnit은 각 매개변수마다 별개의 테스트를 실행시킨다.

6.9 경계 케이스 다루기

우리는 매개변수에 들어올 수 있는 모든 값들을 테스트 할 수 없다. 

따라서 틀리기 쉬운 '경계 케이스'를 다뤄야만 한다.

 

(경계케이스 예시) 

문자열 -> null, "", " ", "a∆¬…˙∑s",

int -> 0, 1, -1, MAX, MIN

Object[] -> null, {}, {null} ..

경계 케이스 테스트 코드 예시

class TransmissionParserTest {

	// 올바르게 parse하는 지 체크
    @Test
    void testValidTransmission() {
        TransmissionParser parser = new TransmissionParser();

        Transmission transmission = parser.parse("032Houston, UFO sighted!");

        Assertions.assertEquals(32, transmission.getId());
        Assertions.assertEquals("Houston, UFO sighted!",
                transmission.getContent());
    }
    
	// null 입력 시 IllegalArgumentException이 잘 발생하는지 체크
    @Test
    void nullShouldThrowIllegalArgumentException() {
        Executable when = () -> new TransmissionParser().parse(null);
        Assertions.assertThrows(IllegalArgumentException.class, when);
    }

	// 이상한 특수문자 입력 시 예외가 잘 발생하는지 체크
    @Test
    void malformedTransmissionShouldThrowIllegalArgumentException() {
        Executable when = () -> new TransmissionParser().parse("t͡ɬɪŋɑn");
        Assertions.assertThrows(IllegalArgumentException.class, when);
    }
}

6.10 6장에서 배운 내용

테스트 코드는 실제 기능 구현 보다 더 많이 작성하는 경우가 많다.

 

따라서, 테스트 집합을 잘 디자인하는 것은 매우 중요하다.

 

테스트는...

given-then-when +

독립적이며 표기를 통해 설명해야하며 +

적절한 어서션을 선택함으로 테스트 이해도를 높여야 한다.