DAY 17

🔖 오늘 읽은 범위 : 9. 단위테스트(154~164p)

---

🤓 책에서 기억하고 싶은 내용

TDD 법칙 세 가지

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

• 법칙을 따르면 개발과 테스트가 30초 주기로 묶이고 테스트 코드가 실제 코드보다 불과 몇 초 전에 나온다

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

• 실제 코드가 진화하면 테스트 코드도 변해야 한다
• 테스트 코드가 지저분할 수록 변경하기 어려워진다.
• 테스트 코드가 복잡할 수록 실제 코드를 짜는 시간보다 테스트 케이스를 추가하는 시간이 더 걸리기 십상
• 새 버전을 출시할 때마다 테스트 케이스 유지, 보수하는 비용도 늘어난다.
• 하지만 테스트 슈트가 없으면 개발자는 수정한 코드가 제대로 도는지 확인할 방법이 없다.
• 의도하지 않은 결함 수가 많아지면 개발자는 변경을 주저한다 → 기존 코드를 정리하지않는다 → 코드가 더러워지기 시작한다
• 애초에 테스트 코드를 잘 짜야한다.

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

• 단위 테스트: 코드에 유연성, 유지보수성, 재사용성을 제공하는 버팀목
• 자동화된 단위 테스트 슈트는 변경이 쉬워지게 함 → 설계와 아키텍처를 최대한 깨끗하게 보존 가능

깨끗한 테스트 코드

• 가독성은 실제 코드보다 테스트 코드에서 더 중요하다

public void testGetPageHieratchyAsXml() throws Exception {
    crawler.addPage(root, PathParser.parse("PageOne"));
    crawler.addPage(root, PathParser.parse("PageOne.ChildOne"));
    crawler.addPage(root, PathParser.parse("PageTwo"));
    request.setResource("root");
    request.addInput("type", "pages");
    Responder responder = new SerializedPageResponder();
    SimpleResponse response =
        (SimpleResponse) responder.makeResponse(new FitNesseContext(root), request);
    String xml = response.getContent();
    assertEquals("text/xml", response.getContentType());
    assertSubString("<name>PageOne</name>", xml);
    assertSubString("<name>PageTwo</name>", xml);
    assertSubString("<name>ChildOne</name>", xml);
}

public void testGetPageHieratchyAsXmlDoesntContainSymbolicLinks() throws Exception {
    WikiPage pageOne = crawler.addPage(root, PathParser.parse("PageOne"));
    crawler.addPage(root, PathParser.parse("PageOne.ChildOne"));
    crawler.addPage(root, PathParser.parse("PageTwo"));
    PageData data = pageOne.getData();
    WikiPageProperties properties = data.getProperties();
    WikiPageProperty symLinks = properties.set(SymbolicPage.PROPERTY_NAME);
    symLinks.set("SymPage", "PageTwo");
    pageOne.commit(data);
    request.setResource("root");
    request.addInput("type", "pages");
    Responder responder = new SerializedPageResponder();
    SimpleResponse response =
        (SimpleResponse) responder.makeResponse(new FitNesseContext(root), request);
    String xml = response.getContent();
    assertEquals("text/xml", response.getContentType());
    assertSubString("<name>PageOne</name>", xml);
    assertSubString("<name>PageTwo</name>", xml);
    assertSubString("<name>ChildOne</name>", xml);
    assertNotSubString("SymPage", xml);
}

public void testGetDataAsHtml() throws Exception {
    crawler.addPage(root, PathParser.parse("TestPageOne"), "test page");
    request.setResource("TestPageOne");
    request.addInput("type", "data");
    Responder responder = new SerializedPageResponder();
    SimpleResponse response =
        (SimpleResponse) responder.makeResponse(new FitNesseContext(root), request);
    String xml = response.getContent();
    assertEquals("text/xml", response.getContentType());
    assertSubString("test page", xml);
    assertSubString("<Test", xml);
}

• addPage와 assertSubString을 부르느라 중복되는 코드가 매우 많다
• PathParser 는 문자열을 pagePath 인스턴스로 변환 → web crawler 가 사용하는 객체이므로 테스트와 무관
  
• responder, response를 수집해 변환하는 코드 역시 잡음
• 아래와 같이 refactoring

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 testSymbolicLinksAreNotInXmlPageHierarchy() 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");
}

• Build-Operate-Check 패턴
  1. 테스트 자료를 만듬
  2. 테스트 자료를 조작
  3. 결과가 올바른지 확인

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

• DSL: 테스트를 구현하는 당사자와 나중에 테스트를 읽어볼 독자를 도와주는 테스트언어
• 시스템 조작 API 를 사용하는 대신 API 위에다 함수와 유틸리티를 구현한 후 그 함수와 유틸리티를 사용

이중 표준

• 테스트 코드는 실제코드만큼 효율적일 필요는 없다 → 테스트 환경에서 수행되기 때문

@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());
}

• assertTrue, False 읽기 너무 어렵다.
• 아래와 같이 refactoring

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

• 대문자는 ‘켜짐on’이고 소문자는 ‘꺼짐 off’을 뜻한다. 문자는 항상 {heater, blower, cooler, hi-temp-alarm, lo-temp- alarm} 순서
• 그릇된 정보를 피하라 규칙을 위반하지만 테스트 코드에서는 적절하다

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;
}

• 효율을 위해서는 StringBuffer를 사용해야하지만 테스트코드에서는 괜찮다

🤔 떠오르는 생각

• 확실히 프로젝트 메인테이너가 단위 테스트를 잘 작성해놓으면 새로 합류한 인원이 아무렇게나 변경해서 PR을 올려도 두려움이 없고 시스템이 잘 유지 되었었던 경험이 있다

🔎 질문

📝 소감 3줄 요약

• 자동화된 단위 테스트 슈트는 변경이 쉬워지게 함 → 설계와 아키텍처를 최대한 깨끗하게 보존 가능
• 가독성은 실제 코드보다 테스트 코드에서 더 중요하다 → Build-Operate-Check 패턴
• 테스트 코드는 실제코드만큼 효율적일 필요는 없다 → 테스트 환경에서 수행되기 때문