9장. 단위 테스트

테스트 코드는 프로그램이 '돌아간다'는 사실만 확인하는 일회성 코드에서 꼬치꼬치 따지며 코드가 제대로 도는지 확인하는 코드로 발전하였다. 애자일과 TDD 덕택에 단위 테스트를 자동화 하는 경우가 늘어났다.

TDD 법칙 세 가지

TDD는 실제 코드를 짜기 전에 단위 테스트부터 짜라고 요구한다.

• 첫째 법칙 : 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
• 둘째 법칙 : 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
• 셋째 법칙 : 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.

위 세 가지 규칙을 따르면 개발과 테스트가 대략 30초 주기로 묶인다. 테스트 코드와 실제 코드가 함께 나올뿐더러 테스트 코드가 실제 코드보다 불과 몇 초 전에 나온다.그러나 실제 코드와 맞먹을 정도로 방대한 테스트 코드는 심각한 관리 문제를 유발하기도 한다.

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

실제 코드가 진화하면 테스트 코드도 변해야 하는데, 테스트 코드가 지저분할수록 변경하기 어려워진다. 새 버전 출시마다 테스트 케이스 유지보수 비용도 상승하여 결국 테스트 슈트를 폐기해야하는 상황이 나오게 되는데, 테스트 슈트가 없으면 개발자는 자신이 수정한 코드가 제대로 도는지 확인할 방법이 없다. 테스트 코드는 실제 코드 못지 않게 중요하다. 테스트 코드는 실제 코드 못지 않게 깨끗하게 짜야 한다.

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

코드에 유연성, 유지보수성, 재사용성을 제공하는 버팀목은 단위 테스트이다. 테스트 케이스가 없다면 모든 변경이 잠정적인 버그겠지만, 테스트 커버리지가 높을수록 아키텍처가 부실한 코드나 설계가 모호하고 엉망인 코드라도 별다른 우려 없이 변경할 수 있다. 그러모로 실제 코드를 점검하는 자동화된 단위 테스트 슈트는 설계와 아키텍처를 최대한 깨끗하게 보존하는 열쇠다.

깨끗한 테스트 코드

테스트 코드는 최소의 표현으로 많은 것을 나타내야 한다. 그러므로 가독성이 실제 코드보다 더더욱 중요하다.

/* 리팩터링 완료된 테스트 코드 > BUILD-OPERATE-CHECK 패턴이 적합 */

//테스트 자료 생성
public void testGetPageHierarchyAsXml() throws Exception {
	makePages("PageOne", "PageOne.ChildOne", "PageTwo");
    
    submitRequest("root", "type:pages");
    
    assertResponseIsXml();
    assertResponseContains(
    	"<name>PageOne</name>", "<name>PageTwo</name>", "<name>ChildOne</name>"
    );
}

//테스트 자료 조작
public void testSymbolicLinkAreNotInXmlPageHierarchy() throws Exception {
	WikiPage page = makePage("PageOne");
	makePages("PageOne.ChildOne", "PageTwo");
    
    addLinkTo(page, "PageTwo", "SymPage");
    
    submitRequest("root", "type:pages");
    
    assertResponseIsXml();
    assertResponseContains(
    	"<name>PageOne</name>", "<name>PageTwo</name>", "<name>ChildOne</name>"
    );
    assertResponseDoesNotContain("SymPage");
}

//조작 결과 확인
public void testGetDataAsXml() throws Exception {
	makePageWithContent("TestPageOne", "test page");
    
    submitRequest("TestPageOne", "type:data");
    
    assertResponseIsXml();
    assertResponseContains("test page", "<Test");
}

도메인에 특화된 테스트 언어

위 테스트 코드는 도메인에 특화된 언어(DSL)로 테스트 코드를 구현하는 기법을 보여준다.
흔히 쓰는 시스템 조작 API를 사용하는 대신 API 위에다 함수와 유틸리티를 구현한 후, 그 함수와 유틸리티를 사용하는 방식으로, 이렇게 구현한 함수와 유틸리티는 테스트 코드에서 사용하는 특수 API가 된다.

이중 표준

테스트 API에 적용하는 표준은 단순하고 간결하고 표현력이 풍부해야 하지만, 실제 코드만큼 효율적일 필요는 없다. 따라서 실제 환경에서는 절대로 안되지만 테스트 환경에서는 전혀 문제없는 방식이 있다. 대개 메모리나 CPU 효율과 관련있는 경우 코드의 깨끗함과는 무관하게 작성해도 된다.

//EnvironmentControllerTest.java
@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());
}

//리팩토링1, 가독성 개선
@Test
public void turnOnLoTempAlarmAtThreashold() throws Exception {
	wayTooCold();
    assertEquals("HBchL", hw.getState());	//대문자 : 켜짐, 소문자 : 꺼짐
}

//리팩토링2, 1함수 1assert문
@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 turnOnHiTempAlarmAtThreashold() throws Exception {
	wayTooHot();
    assertEquals("hBCHl", hw.getState());
}

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

//getState함수, 효율은 StringBuffer가 적합하나 보기 좋지 않아 미사용
public String getState() {
	String state = "";
    state += heater ? "H" : "h";
    state += blower ? "B" : "b";
    state += cooler ? "C" : "c";
    state += hiTempAlarm ? "H" : "h";
    state += loTempAlarm ? "L" : "l";
    return state;
}

테스트 당 assert 하나

위 BUILD-OPERATE-CHECK 패턴의 예제에서는 "출력이 XML이다" 라는 assert문과 "특정 문자열을 포함한다"는 assert 문을 하나로 병합하는 방식이 불합리해 보인다. 그런 경우 다음과 같이 테스트를 두 개로 쪼개 각자가 assert를 수행하도록 한다.

/* given-when-then 구문 사용 > 중복 과다 */
public void testGetPageHierarchyAsXml() throws Exception {
	givenPages("PageOne", "PageOne.ChildOne", "PageTwo");
    
    whenRequestIsIssued("root", "type:pages");
    
    thenResponseSholdBeXml();
}

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

위 처럼 사용 시 중복되는 코드가 많아지므로, TEMPLATE METHOD 패턴을 사용하면 중복을 제거할 수 있다. given/when 부분을 부모 클래스에 두고 then 부분을 자식 클래스에 두거나, @Before 함수에 given/when 부분을 넣고, @Test 함수에 then 부분을 넣어도 된다.
'단일 assert문' 은 좋은 지침이지만, 때로는 필요에 따라 함수 하나에 여러 assert문을 넣는 것이 더 효율적일 수 있다. 단, assert문 개수는 최대한 줄여야 좋다.

테스트 당 개념 하나

이것저것 잡다한 개념을 연속으로 테스트하는 긴 함수는 피해야 한다. 가장 좋은 규칙은 다음 두 가지이다.

• 개념 당 assert 문 수를 최소로 줄여라
• 테스트 함수 하나는 개념 하나만 테스트하라

F.I.R.S.T.

깨끗한 테스트는 다음 다섯가지 규칙을 따른다.

• 빠르게 Fast : 테스트는 빨리 돌아야 한다. 느리면 자주 돌릴 수 없고, 자주 돌리지 못하면 초반에 문제를 찾아내 고치거나 마음껏 정리할 수 없어 코드 품질이 망가진다.
• 독립적으로 Independent : 각 테스트는 서로 의존하면 안된다. 각 테스트는 독립적으로, 어떤 순서로 실행해도 괜찮아야 한다. 의존 시 하나가 실패할 때 나머지도 잇달아 실패해 원인을 진단하기 어려워지며, 후반 테스트가 찾아내야 할 결함이 숨겨진다.
• 반복가능하게 Repeatable : 테스트는 어떤 환경에서도 반복 가능해야 한다. 실제 환경, QA 환경, 네트워크에 연결되지 않은 환경에서도 실행할 수 있어야 한다.
• 자가검증하는 Self-Validating : 테스트는 부울값으로 결과를 내야한다. 성공 아니면 실패다. 통과 여부를 알려고 로그 파일을 읽게 하거나 텍스트 파일 두 개를 수작업으로 비교하게 만들면 안된다.
• 적시에 Timely : 테스트는 적시에 작성해야 한다. 단위 테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현한다.

깨끗한 테스트코드를 유지하는 것은 어쩌면 실제 코드보다 더 중요할 수 있다. 테스트코드는 실제 코드의 유연성, 유지보수성, 재사용성을 보존하고 강화하기 때문이다.
아래 조건이 충족되면 테스트 코드를 지속적으로 깨끗하게 관리하기가 수월하다.

• 표현력을 높이고 간결하게 정리
• 테스트 API를 구현해 도메인 특화 언어(DSL) 을 생성