Clean Code 9장 - 단위테스트

Clean Code - 단위테스트

실제 코드를 작성하기 전에 단위 테스트를 작성하라

첫번째 법칙 : 실패하는 단위 테스트를 작성하기 전에 실제 코드를 작성하지 않는다.

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

세번째 법칙 : 현재 실패하는 테스트를 통과할 정도로만 코드를 작성한다.

위의 법칙대로 작성을 하면 테스트 코드와 실제 코드가 빠른 주기로 묶인다. 이렇게 되면, 실제 코드와 맞먹는 정도의 방대한 테스트 코드가 나와 심각한 관리 문제가 생긴다.

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

테스트 코드는 메인 코드와 다르게 대충 짜도 된다는 의식을 많이 가지고 있다. 테스트 코드를 대충 짜면 어떠한 문제가 생길까?

• 메인 코드 버전업 -> 테스트 실패
• 테스트 코드를 수정해야 하지만 더러운 코드 때문에 수정이 어려워짐
• 테스트 코드 유지보수에 시간이 많이 든다고 착각한채, 테스트 코드 포기
• 서비스의 결합율이 높아짐

위의 문제 때문에 테스트 코드 또한 깔끔하게 짜야한다.

테스트 코드 깔끔하게 짜기 - BUILD OPERATE CHECK 패턴

테스트 함수 안에 for문, if문 등 가장 로우레벨의 코드를 쭉 나열했다면, 나중에 다른 팀원이 읽을 때나 리팩토링 할 때 가독성이 떨어진다. 

테스트 코드는 또 하나의 가이드라 생각하면 된다. 

깔끔한 테스트 코드를 짤 때 BUILD OPERATE CHECK 패턴이 적합하다.

아래의 예시를 보면,

1.  테스트를 위해 기본 설정

2. 실제 테스트 자료를 조작

3. 조작한 결과가 맞는지 확인

와 같은 구조로 작성되어 있다.

위와 같이 짜면, 코드를 읽는 사람은 세세한 코드에 신경쓰지 않고 코드가 수행하는 기능을 빠르게 읽어나갈 수 있다.

@Test
public void test_get_data_as_xml() {
  // build
  makePageWithContent("TestPageOne", "test page");

  // operate
  submitRequest("TestPageOne");

  // check
  assertResponseContains("test page", "<Test");
}

테스트 당 개념 하나

테스트 당 개념하나라고 해서 assert문이 꼭 하나만일 필요는 없다.

단지, 테스트 코드를 읽는 사람과 깔끔한 테스트를 위해 하나의 테스트 함수에서는 하나의 개념만을 테스트 해야 한다.

F.I.R.S.T

• Fast : 테스트가 빨라야 자주 돌리게 되고, 버림받지 않게 된다. 
• Independent : 다른 테스트와 독립적으로 돌아야 한다. 만약 특정 테스트끼리 연관이 되어있다면 
• Repeatable : 테스트는 어떠한 환경에서도 반복 가능해야 한다. Dev, Staging, Prod 어떤 환경에서도 테스트 할 수 있도록 짜야 한다. 환경 때문에 테스트가 할 수 없다면 테스트가 실패한 이유를 둘러댈 변명이 생긴다.
• Self-Validating : 테스트 결과는 무조건 Boolean 값으로 결과를 내야 한다. 개발자가 다시 로그를 해석하는 일은 없어야 한다.
• Timely : 테스트 코드는 실제 코드를 작성하기 전에 작성되어야 한다.