[Clean Code] 9장 단위 테스트

『Clean Code(클린 코드) 애자일 소프트웨어 장인 정신 - 로버트 C. 마틴』 을 읽고 요약한 내용입니다.

테스트 케이스를 모두 구현하고 통과한 후에는 내 코드를 사용할 사람들에게도 공개했으리라. 테스트 코드와 내 코드를 같은 소스 패키지로 확실하게 묶어 체크인했으리라.
애자일과 TDD 덕택에 단위 테스트를 자동화하는 프로그래머들이 이미 많아졌으며 점점 더 늘어나는 추세다. 하지만 우리 분야에 테스트를 추가하려고 급하게 서두르는 와중에 많은 프로그래머들이 제대로 된 테스트 케이스를 작성해야 한다는 좀 더 미묘한 (그리고 더욱 중요한) 사실을 놓쳐버렸다.

TDD 법칙 세 가지
1. 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
2. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
3. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.
깨끗한 테스트 코드 유지하기
테스트 코드는 실제 코드 못지 않게 중요하다. 테스트 코드는 이류 시민이 아니다. 테스트 코드는 사고와 설계와 주의가 필요하다. 실제 코드 못지 않게 깨끗하게 짜야 한다.
- 테스트는 유연성, 유지보수성, 재사용성을 제공한다.
- 코드에 유연성, 유지보수성, 재사용성을 제공하는 버팀목이 바로 단위 테스트이다. 테스트 케이스가 없다면 모든 변경이 잠정적인 버그다. 아키텍처가 아무리 유연하더라도, 설꼐를 아무리 잘 나눴더라도, 테스트 케이스가 없으면 개발자는 변경을 주저한다. 버그가 숨어들까 두렵기 때문이다.

깨끗한 테스트 코드
중요한 것은 가독성이다. 명료성, 단순성의 풍부한 표현력이 필요하다. 테스트 코드는 최소의 표현으로 많은 것을 나타내야 한다.
```
// p.160 리팩토링한 테스트 코드
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");
}
```
좀 더 깨끗한 테스트 구조. 각 테스트는 명확히 세 부분으로 나눠진다.
1. 테스트 자료를 만든다.
2. 테스트 자료를 조작한다.
3. 조작한 결과가 올바른지 확인한다.
→ 잡다하고 세세한 코드를 거의다 없애 온갖 잡다하고 세세한 코드에 주눅들고 헷갈릴 필요 없이 코드가 수행하는 기능을 재빨리 이해하도록 한다.
- 도메인에 특화된 테스트 언어 DSL
  테스트를 구현하는 당사자와 나중에 테스트를 읽어볼 독자를 도와주는 테스트 언어
  숙련된 개발자라면 자기 코드를 좀 더 간결하고 표현력이 풍부한 코드로 리팩터링해야 마땅하다.
- 이중 표준
  테스트 API 코드에 적용하는 표준은 실제 코드에 적용하는 표준과 확실히 다르다. 단순하고, 간결하고, 표현력이 풍부해야 하지만, 실제 코드만큼 효율적인 필요는 없다. 실제 환경과 테스트 환경은 요구사항이 판이하게 다르다.
  
  애플리케이션은 확실히 실시간 임베디드 시스템이다. 즉, 컴퓨터 자원과 메모리가 제한적일 가능성이 높다. 하지만 테스트 환경은 자원이 제한적일 가능성이 낮다. (이중 표준)
  
  실제 환경에서는 절대로 안 되지만 테스트 환경에서는 전혀 문제없는 방식이 있다. 대게 메모리나 CPU 효율과 관련있는 경우다. 코드의 깨끗함과는 철저히 무관하다.

테스트 당 assert 하나

@Test
void testGetPageHierarchyAsXml() {
    // given
    givenPages("pageOne", "PageOne.ChildOne", "PageTwo");
    // when
    whenRequestIsIssued("roots", "type::pages");
    // then
    thenResponseShouldBeXml();
}

→ 불행하게도 테스트를 분리하면 중복되는 코드가 많아진다.
Template Method 패턴을 사용하면 중복을 제거할 수 있다. given, when 부분을 부모 클래스에 두고 then 부분을 자식 클래스에 두면 된다.
또는
@Before 함수에 given, when 부분을 넣고 @Test 함수에 then 부분을 넣어도 된다.
assert문을 여럿 사용하는 편이 좋을때도 있다. 단지 assert 문의 개수는 최대한 줄여야 한다.
- 테스트당 개념 하나
  - 가장 좋은 규칙은“테스트 함수 하나는 개념 하나만 테스트하라”
  - “개념 당 assert 문 수를 최소로 줄여라”
  - “테스트 함수마다 한 개념만 테스트하라”는 규칙이 더 낫다.”

F.I.R.S.T
깨끗한 테스트는 다섯가지 규칙을 따른다.
1. Fast 빠르게
  테스트는 빨라야한다. 빨리 돌아야 한다는 말이다. 자주 돌려서 초반에 문제를 찾아내고, 마음껏 정리할 수 있어야 한다.
2. Independent 독립적으로
  각 테스트는 서로 의존하면 안 된다. 한 테스트가 다음 테스트가 실행될 환경을 준비해서는 안 된다. 각 테스트는 독립적으로, 어떤 순서로 실행해도 괜찮아야 한다. 서로 의존하면 하나가 실패하면 연달아 실패하므로 후반 테스트가 찾아야 할 결함이 숨겨진다.
3. Repeatable 반복가능하게
  어떤 환경에서도 반복 가능해야 한다. 네트워크가 연결되지 않은 노트북 환경에서도 실행할 수 있어야 한다. 테스트가 돌아가지 않는 환경이 하나라도 있다면 테스트가 실패한 이유를 둘러댈 변명이 생긴다. 게다가 환경이 지원되지 않으면 테스트를 수행하지 못하는 상황에 직면하게 된다.
4. Self-Validating 자가검증하는
  테스트는 bool 값으로 결과를 내야 한다. 성공 아니면 실패다. 통과 여부를 알려고 로그 파일을 읽게 만들어서는 안 된다. 통과 여부를 보려고 텍스트 파일 두 개를 수작업으로 비교하게 만들어서도 안 된다. 테스트가 스스로 성공과 실패를 가늠하지 않는다면 판단은 주관적이 되며 지루한 수작업 평가가 필요하게 된다.
5. Timely 적시에
  적시에 작성해야 한다. 단위 테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현한다. 실제 코드를 구현한 다음에 테스트 코드를 만들면 실제 코드가 테스트하기 어렵다는 사실을 발견할지도 모른다. 실제 코드는 테스트하기 너무 어렵다고 판명날지도 모르며 테스트가 불가능하도록 실제 코드를 설계할지도 모른다.
결론
- 테스트 코드는 실제 코드만큼이나 프로젝트 건강에 중요하다. 어쩌면 실제 코드보다 더 중요할지도 모르겠다. 테스트 코드는 실제 코드의 유연성, 유지보수성, 재사용성을 보존하고 강화하기 때문이다. 그러므로 테스트 코드는 지속적으로 깨끗하게 관리하자. 표현력을 높이고 간결하게 정리하다. 테스트 APU를 구현해 도메인 특화 언어 Domain Specific Language를 만들자. 그러면 그만큼 테스트 코드를 짜기가 쉬워진다.
- 테스트 코드가 방치되어 망가지면 실제 코드도 망가진다. 테스트 코드를 깨끗하게 유지하자.

티스토리툴바