북클럽 클린코드 9장. 단위 테스트

TDD 법칙 세 가지

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

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

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

• 일회용 테스트 코드와 단위 테스트는 간극이 아주 크다.
• 실제 코드가 변화하면 테스트 코드도 같이 변해야 한다.
  • 테스트 코드가 더러우면 변경하기가 어려워진다.
  • 테스트 코드가 복잡할수록 변경하는 시간이 더 걸린다.
• 테스트 코드를 막 짜도 좋다고 허용한 결정이 잘못된 거다.
• 테스트 코드는 실제 코드 못지 않게 중요하다.
• 테스트 코드는 사고와 설계와 주의가 필요하다.
• 실제 코드 못지 않게 깨끗하게 짜야 한다.

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

• 코드 변경의 버팀목이 된다.

깨끗한 테스트 코드

• 가독성이 제일 중요하다.
• 가독성은 실제 코드보다 테스트 코드에 더더욱 중요하다.
  • 테스트 의도가 이해되어야 하기 때문에
• Build-Operate-Check 패턴으로 작성하자

테스트 API 코드에 적용하는 표준은 실제 코드에 적용하는 표준과 확실히 다르다.
테스트 코드는 가독성이 제일 중요하다.
String Buffer는 보기 흉하다. 저자는 실제 코드에서도 크게 무리가 아니라면 StringBuffer를 피한다고 함.

테스트 당 assert 하나

• 결론이 하나이기 때문에 코드를 이해하기 쉽고 빠르다.

테스트 당 개념 하나

• 이 말이 더 낫다.
• 잡다한 개념을 연속으로 테스트하는 긴 함수는 피한다.
• 이해하기 힘들어짐. 복잡해짐. 이름이 불명확해짐.
• 한 함수에 대한 테스트에 given이 세개 존재하는 경우

개념 당 assert 문 수를 최소로 줄이고 테스트 함수 하나는 개념 하나만 테스트하자.

FIRST

• 깨끗한 테스트 다섯 가지 규칙
• Fast(빠르게)
• Independent(독립적으로) : 테스트 간 의존성 제거. 테스트는 독립적이고 순서 상관없이
• Repeatable(반복가능하게)
• Self-Validating(자가검증하는) : 로그 말고 true, false로 구분되게 해야됨
• Timely(적시에) : 테스트 코드 없이 실제 코드를 작성하면 테스트가 불가능하도록 실제 코드를 작성할 수 있다