9장 단위 테스트

제대로 된 실제 코드, 그리고 필수적인 제대로 된 테스트 코드

 

TDD 제 3원칙

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

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

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

 

이렇게 작성하게 되면 많은 테스트 코드가 발생하면서 실제 코드와도 맞먹을 수준이 되며 많은 문제를 야기할 수 있다.

 

단위테스트를 그럼 마구잡이로 작성하게 된다면 어떤 문제가 생길까?

실제 코드의 테스트 속도를 빨라진다.

그러나!

일회성으로만 짰기 때문에 자동화된 단위 테스트를 짜기 쉽지 않다.  왜냐하면 실제 코드가 변화하면 테스트도 변화해야 하는데 테스트 코드가 엉망진창이면 답도 없어지게 된다. 그리고 테스트 통과도 어려워지게 되며 부담스러워지게 된다. 그렇게 된다면 버전이 출시 될 때마다 비용가 시간이 기하급수적으로 상승하게 된다.

그렇다고 테스트 코드를 작성하지 않는다면 실제코드의 테스팅이 불가하기 때문에 사실 검증을 위해 테스트 코드를 사용해야 한다.

그렇기에 제대로된 실제 코드는 제대로 된 테스트 코드라는 것이다.

 

 

제대로 된 테스트 코드

 

테스트 코드는 실제 코드만큼 효율적인 필요가 없으니 가독성에 집중해야 한다.

@Test
public void turnOnLoTempAlarmThreashold() throws Exception{
	hw.setTemp(WAY_TOO_COLD)
    controller.tic();
    assertTrue(hw.heaterState);
    assertFalse(hw.blowerState);
    assertTrue(hw.coolerState);
    assertTrue(hw.hiTempAlarm);
    assertFalse(hw.loTempAlarm);
}

/*
	온도를 낮췄을 때
    각 상태의 변화를 체크하는 테스트
    가독성이 매우 안좋다. 각 상태를 이리저리 눈을 돌리며 확인한다 ㅠㅠ
*/

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

@Test
public void turnOnLoHeaterAndCooler throws Exception{
	tooHot();
    assertEquals("HbchL", hw.getState());
}

/*
	'HbchL' 같은 문자열의 경우 그릇된 정보를 피하라는 규칙에 어긋나지만,
    하지만 의미를 안다면 아주 결과를 판단하기에 적절한 사례가 된다.
*/

 

+ 대게 테스트 코드는 메모리나 CPU효율과 관련있는 경우에 깨끗함과는 무관해진다.

+ 최소 확인 함수인 assert문이 적을 수록 좋지만 중복 코드가 많이 발생하는 경우 assert문 여러개도 고려한다.

+ 테스트 하나당 하나의 개념(여기서 하나의 개념은 비슷한 작업 중 하나로 생각)

 

F.I.R.S.T

 

Fast > 테스트는 빠르게 돌려야 한다. 우리는 간단하고 명확한 테스트를 위하지 정밀한 테스트를 원하지 않는다.

Indepentent > 각 테스트는 의존 x, 실행순서에도 상관없이 동작이 되어야 한다. 의존 시 쓰레기 코드가능성이 높다.

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

Self-Validating > 테스트는 boolean 값으로 결과를 내 성공/실패를 명확히 해야한다.

Timely > 테스트는 적시에 작성해야 한다. 테스트 코드 작성 전 실제 코드를 작성해야 한다.

 

 

 

결론 

(실제 코드 = 테스트 코드) 라는 마음가짐과 작성.