클린코드 9장 단위테스트

들어가며…

테스트 코드 작성 경험 X 난항이 예상된다…

TDD : Test Driven Development

대다수에게 단위테스트란 자기 프로그램이 ‘돌아간다’는 사실만 확인하는 일회성 코드에 불과

클래스와 메서드를 공들여 구현후 임시 코드를 급조해 테스트를 수행, 대개는 간단한 드라이버 프로그램을 구현해 자신이 짠 프로그램을 수동으로 실행

에자일과 TDD 덕택에 단위 테스트를 자동화하는 프로그래머들이 이미 많아졌으며 점점 더 늘어나는 추세다. 많은 프로그래머들이 제대로 된 테스트 케이스를 작성해야 한다는 좀 더 미묘한(그리고 더욱 중요한)사실을 놓쳐버렸다.

TDD 법칙 세가지

-실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.

-컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.

-현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.

위 세가지 규칙을 따르면 개발과 테스트가 대략 30초 주기로 묶인다. 테스트 코드와 실제 코드가 함께 나올뿐더러 테스트 코드가 실제 코드보다 불과 몇 초 전에 나온다.

이렇게 일하면 매일 수십개..쭉쭉가면 실제 코드를 사실상 전부 테스트하는 테스트 케이스가 나옴.

하지만 실제 코드와 맞먹을 정독로 방대한 테스트 코드는 심각한 관리 문제를 유발하기도 한다.

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

일회용 테스트 코드를 짜오다가 새삼스레 자동화된 단위 테스트 슈트를 짜기란 쉽지않다. 지저분한 테스트 코드를 내놓으나 테스트를 안하나, 아니 오히려 더 못하다는 사실. 문제는 실제 코드가 진화하면 테스트 코드도 변해야한다. 테스트 코드가 지저분할수록 변경하기 어려워진다. 또한 테스트 코드가 복잡할수록 실제 코드를 짜는 시간보다 테스트 케이스를 추가하는 시간이 더 걸리기 십상이다.

실제코드변경 → 기존 테스트 케이스 실패하기 시작 → 지저분한 코드로 인해 실패하는 테스트 케이스를 점점 통과하기 어려워짐 → 테스트 코드 계속해서 늘어남

테스트 코드는 실제코드 못지 않게 중요함. 사고와 설계와 주의가 필요. 실제 코드 못지 않게 깨끗하게 짜야한다.

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

테스트 코드를 깨끗하게 유지하지 않으면 결국은 잃어버린다. 그리고 테스트 케이스가 없으면 실제 코드를 유연하게 만드는 버팀목도 사라짐. 코드에 유연성, 유지보수성, 재사용성을 제공하는 버팀목 →단위 테스트 . 테스트 케이스가 있으면 변경이 두렵지 않으니까! (답지가 있는느낌..?)

실제코드를 점검하는 자동화된 단위 테스트 슈트는 설계와 아키텍처를 최대한 깨끗하게 보존하는 열쇠. 테스트 케이스가 있으면 변경이 쉬워진다.

깨끗한 테스트 코드

깨끗한 테스트 코드를 만들려면? 세가지가 필요함. 가독성. 가독성. 가독성

가독성은 실제 코드보다 테스트 코드에 더더욱 중요. 가독성을 높이려면? 명료성,단순성,풍부한 표현력이 필요

최소의 표현으로 많은 것을 나타내야 한다..

이 부분은 좀 어렵네요…

아래 테스트 케이스 세 개는 이해하기 어렵기에 개선할 여지가 충분하다. 첫째, addPage와 assertSubString을 부르느라 중복되는 코드가 매우 많다. 좀 더 중요하게는 자질구레한 사항이 너무 많아 테스트 코드의 표현력이 떨어진다.

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

예를 들어, PathParser 호출을 살펴보자. PathParser는 문자열을 pagePath 인스턴스로 변환한다. 이 코드는 테스트와 무관하며 테스트 코드의 의도만 흐린다. responder 객체를 생성하는 코드와 response를 수집해 변환하는 코드 역시 잡음에 불과하다. 게다가 resource와 인수에서 요청 URL을 만드는 어설픈 코드도 보인다.

마지막으로 위 코드는 읽는 사람을 고려하지 않는다. 불쌍한 독자들은 온갖 잡다하고 무관한 코드를 이해한 후라야 간신히 테스트 케이스를 이해한다.

이제 목록 9-2를 살펴보자. 목록 9-1을 개선한 코드로, 목록 9-1과 정확히 동일한 테스트를 수행한다. 하지만 목록 9-2는 좀 더 깨끗하고 좀 더 이해하기 쉽다.

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 패턴이 위와 같은 테스트 구조에 적합하다. 각 테스트는 명확히 세 부분으로 나눠진다. 첫 부분은 테스트 자료를 만든다. 두 번째 부분은 테스트 자료를 조작하며, 세 번째 부분은 조작한 결과가 올바른지 확인한다.

잡다하고 세세한 코드를 거의 다 없앴다는 사실에 주목한다. 테스트 코드는 본론에 돌입해 진짜 필요한 자료 유형과 함수만 사용한다. 그러므로 코드를 읽는 사람은 온갖 잡다하고 세세한 코드에 주눅들고 헷갈릴 필요 없이 코드가 수행하는 기능을 재빨리 이해한다.

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

시스템 특화 api를 사용하는 대신 api 위에다 함수와 유틸리티를 구현한 후 그 함수와 유틸리티를 사용하면 테스트 코드를 짜기도 읽기도 쉬워진다. 이런 테스트 api는 잡다하고 세세한 사항으로 범벅된 코드를 계속 리팩터링하다가 진회된 api다. 숙련된 개발자라면 자기 코드를 좀 더 간결하고 표현력이 풍부한 코드로 리팩터링해야 마땅하다..

이중표준

테스트API 코드에 적용하는 표준은 실제 코드에 적용하는 표준과 확실히 다르다.실제 환경과 테스트 환경은 요구사항이 판이하게 다르다.실제 환경에서는 안되지만 테스트 환경에는 문제 없는 방식이 있다. 대게 메모리나 cpu 효율과 관련있는 경우.

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

. 온도가 '급격하게 떨어지면' 경보, 온풍기, 송풍기가 모두 가동되는지 확인하는 코드이다.

물론 위 코드는 세세한 사항이 아주 많다. 예를 들어, tic함수가 무엇인지 지금은 신경쓰지 말자. 단지 시스템 최종 상태의 온도가 "급강하"했는지 그것만 신경 써서 살펴보기 바란다.

목록 9-3을 읽으면 점검하는 상태 이름과 상태 값을 확인하느라 눈길이 이리저리 흩어진다. heaterState라는 상태 이름을 확인하고 왼쪽으로 눈길을 돌려 assertTrue를 읽는다. 이런식으로 모든 state를 확인해야 하면 따분하고 미덥잖다. 읽기가 어렵다. 그래서 목록 9-4와 같이 변환해 코드 가독성을 크게 높였다.

목록 9-4 EnvironmentControllerTest.java(리팩터링)

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

당연히 tic 함수는 wayTooCold라는 함수를 만들어 숨겼다. 그런데 assertEquals에 들어있는 이상한 문자열에 주목한다. 대문자는 '켜짐'이고 소문자는 '꺼짐'을 뜻한다. 문자는 항상 '{heater, blower, cooler, hi-temp-alarm, lo-temp-alarm}' 순서다.

비롯 위 방식이 그릇된 정보를 피하라는 규칙의 위반에 가깝지만 여기서는 적절해 보인다. 일단 의미만 안다면 눈길이 문자열을 따라 움직이며 결과를 재빨리 판단한다. 테스트 코드를 읽기가 사뭇 즐거워진다. 목록 9-5를 살펴보면 테스트 코드를 이해하기 너무도 쉽다는 사실이 분명히 드러난다.

목록 9-5 EnvironmentControllerTest.java (bigger selection)

@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 turnOnHiTempAlarmAtThreshold() throws Exception {
  wayTooHot();
  assertEquals("hBCHl", hw.getState());
}

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

목록 9-6은 'getState' 함수를 보여준다. 코드가 그리 효율적이지 못하다는 사실에 주목한다. 효율을 높이려면 StringBuffer가 더 적합하다.

목록 9-6 MockControlHardware.java

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는 보기에 흉하다. 나는 실제 코드에서도 크게 무리가 아니라면 이를 피한다. 목록 9-6은 StringBuffer를 안 써서 치르는 대가가 미미하다. 실제 환경에서는 문제가 될 수 있지만 테스트 환경은 자원이 제한적일 가능성이 낮기 때문이다.

테스트 당 assert 하나

assert 문이 하나인 함수는 결론이 하나라서 코드를 이해하기 쉽다. 함수 하나에 assert 하나만 들어갈 수 있도록 노력하자.

테스트를 분리하면 중복되는 코드가 많아진다.

TEMPLATE METHOD 패턴 [GOP] 사용하면 중복 제거할 수 있다. given/when 부분을 부모 클래스에 두고 then 부분을 자식 클래스에 두면 된다. 아님녀 완전히 독자적인 테스트 클래스를 만들어 @Before 저함수에 given/when 부분을 모두넣고 @Test 함수에 then 부분을 넣어도 된다.

(템플릿 메소드 패턴이란 특정 작업을 처리하는 일부분을 서브 클래스로 캡슐화하여 전체적인 구조는 바꾸지 않으면서 특정 단계에서 수행하는 내용을 바꾸는 패턴입니다. 디자인 패턴이라고 하기도 뭐할정도로 객체지향 언어로 개발을 하다보면 무의식적으로 사용하는 패턴입니다. 주로 개발을 하다보면 구체적인 구현은 다르지만 기본적인 기능은 비슷한 경우가 종종 있습니다.두개 이상의 프로그램이 기본적으로 동일한 골격 하에서 동작할때 기본 골격에 해당하는 알고리즘은 일괄적으로 관리하면서 각 프로그램마다 달라지는 부분들에 대해서는 따로 만들고 싶을때 템플릿 메소드 패턴을 사용하면 좋습니다.)

하지만 때로는 함수 하나에 여러 assert문을 넣기도 한다. 단지 assert 문 개수는 최대한 줄여야 좋다는 저자의 생각.

assert란?

뒤의 조건이 True가 아니면 AssertError를 발생한다. 원하는 조건의 변수 값을 보증받을 때까지 assert로 테스트 할 수 있다.

디버깅할 때 사용 하는 것으로,

조건문 등이 있는, 제대로 작동하고 있는지 확인하고 싶은 코드들 중간에 assert(조건문); 을 입력하게 되면,

조건문이 만족되지 않을 경우 프로그램이 그 시점에서 강제 종료가 되게끔 해준다.

테스트 당 개념 하나

테스트 함수마다 한 개념만 테스트하라

FIRST

깨끗한 테스트는 다음 다섯가지 규칙을 따름. 첫글자를 따오면 FIRST가 된다.

Fast 빠르게 - 테스트는 빨리 돌아야 한다

Independent 독립적으로 - 각 테스트는 서로 의존하면 안 된다. 그리고 어떤 순서로 실행해도 괜찮아야 한다. 서로에게 의존하면 하나 실패할때 나머지도 잇달아 실패하므로 원인 진단 어려움, 후반 테스트가 찾아내야 할 결함이 숨겨짐

Reapeatable 반복가능하게- 테스트는 어떤 환경에서도 반복 가능해야함

Self-Validating 자가검증하는 - 테스트는 부울bool 값으로 결과를 내야함 성공 아님녀 실패

Timely 적시에 - 테스트는 적시에 작성해야 함. 단위 테스트는 테스트 하려는 실제 코드를 구현하기 직전에 구현한다. 실제 코드를 구현한 다음에 테스트 코드를 만들면 실제 코드가 테스트 하기 어렵다는 사실을 발견할지도 모름. 어떤 실제 코드는 테스트하기 너무 어렵다고 판명, 테스트가 불가능 하도록 실제 코드를 설계할지도 모른다.

결론

이 정도는 수박 겉핥기다!(충격)

테스트 코드는 실제 코드만큼이나 프로젝트 건강에 중요. 어쩌면 실제 코드보다 더 중요할지도 모르겠다.

테스트 코드는 실제 코드의 유연성, 유지 보수성, 재사용성을 보존하고 강화하기 때문. 테스트 코드는 지속적으로 깨끗하게 관리하자. 표현력을 높이고 간결하게 정리하자. 테스트 api를 구현해 도메인 특화 언어Domain Specific language DSL를 만들자. 테스트 코드가 방치되어 망가지면 실제 코드도 망가진다. 테스트 코드를 깨끗하게 유지하자.