[Clean Code] 단위 테스트

Clean Code를 읽고 내용을 정리한 것입니다.

책 구매하러 가기

단위 테스트

TDD의 법칙

1. 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
2. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
3. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.

위의 규칙을 따르면 매일 굉장히 많은 테스트 코드가 산출물로 작성될 것이다.

SW 오류를 조금 더 정확하게 짚어낼 수 있겠지만 방대한 테스트 코드는 관리 문제를 유발하기도 한다.

깨끗한 테스트 코드 유지하기

지저분한 테스트 코드는 없는 것보다 못할 수도 있다.

테스트 코드가 굉장히 많이 작성되어 있는데 SW의 스펙이 변경된다면 실제 코드도 변경해야 한다.

실제 코드가 변경되면 테스트 코드는 반드시 같이 변경되어야 한다.

또 테스트 코드가 너무 많다면 실제 코드보다 테스트 케이스를 추가하는 시간이 더 걸릴 수도 있다.

테스트 코드는 실제 코드를 작성하듯 신중하고 깨끗하게 작성해야 한다.

테스트 코드는 유연성, 유지보수성, 재사용성을 제공한다

테스트 코드가 있으면 코드 변경이 두렵지 않다.

내가 틀렸다면 알아서 검증해주기 때문이다.

테스트 케이스가 없으면 모든 변경이 잠정적인 버그이다.

테스트 코드가 지저분하면 코드를 변경하는 능력 또한 떨어진다.

깨끗한 테스트 코드

1. 가독성
2. 가독성
3. 가독성

가독성은 몇 번을 강조해도 부족하다.

테스트 코드는 최소의 표현으로 명료하게 나타내야 한다.

public void testGetPageHierarchyAsXML() throws Exception {
    makePages("pageOne", "pageOne.childOne", "pageTwo");
    submitRequest("root", "type:pages");

    assertResponseIsXML();
    asserResponseContains("<name>pageOne</name>",
        "<name>pageTwo</name", "<name>childOne</name");
}

위의 코드를 보면 makePages를 정확히 명세하지 않았지만 어떤 역할을 할 것인지 짐작하기 쉬울 것이다.

하나의 개념에선 하나만 테스트

몇 개의 개념을 하나의 테스트에서 같이 진행하게 되면 코드를 읽는 사람이 그 모든 개념을 한 번에 이해해야 한다.

public void testAddMonths() {
    SerialDate d1 = SerialDate.createInstance(2004, 5, 31);

    SerialDate d2 = SerialDate.addMonths(1, d1);
    asserEquals(2004, d2.getYYYY());
    asserEquals(6, d2.getMonth());
    asserEquals(30, d2.getDayOfMonth());

    SerialDate d3 = SerialDate.addMonths(2, d1);
    asserEquals(2004, d3.getYYYY());
    asserEquals(7, d3.getMonth());
    asserEquals(31, d3.getDayOfMonth());

    SerialDate d4 = SerialDate.addMonths(1, SerialDate.addMonths(1, d1);
    asserEquals(2004, d4.getYYYY());
    asserEquals(7, d4.getDayOfMonth());
    asserEquals(30, d4.getMonth());
}

위의 코드를 해석해보자.

일단, 메소드명으로 짐작컨대 날짜를 월 단위로 계산하는 테스트 코드로 보인다.

5월 31일에서 한 달을 더하면 6월 30일이 된다.

5월 31일에서 두 달을 더하면 7월 31일이 된다.

5월의 마지막 날에서 더했기 때문에 6월 마지막, 7월 마지막으로 설정된 것이다.

d4는 5월 31일에서 1달을 더하고(6/30), 거기에 1달을 더 더한다.

그래서 7월 30일이 나왔다.

이 코드에서는 여러 개념이 한 번에 등장했다.

1. addMonths는 일 단위가 아니라 월 단위로만 계산한다.
2. 말일에서 1달을 더하면 다음 달 말일이 된다.
3. 최종 값은 중간 값의 결과에 따라 달라질 수 있다(d4).

개념을 최소한으로 줄이면 한 단위의 코드에서 이해해야 하는 양을 줄일 수 있다.

FIRST 법칙

깨끗한 테스트는 FIRST 규칙을 따른다.

1. Fast

   • 테스트는 빨라야 한다.
   • 느린 테스트는 돌릴 때마다 두렵다.

2. Independent

   • 각 테스트는 독립적이어야 한다.
   • 한 테스트가 다음 테스트의 환경을 준비해선 안 된다.
   • 의존성이 생기면 테스트가 연달아 실패한다.

3. Repeatable

   • 테스트는 어떤 환경에서도 반복 가능해야 한다.

4. Self-Validation

   • 테스트는 성공/실패 중 하나의 값만 가져야 한다.
   • 테스트가 스스로 성공/실패를 가늠하지 못하면 주관적인 판단이 개입될 수 있다.

5. Timely

   • 테스트는 적시에 작성해야 한다.
   • 단위 테스트는 테스트하려는 실제 코드를 구현하기 전에 먼저 구현한다.