[클린 코드] 9장. 단위 테스트

1. TDD 법칙 세 가지

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

• 위 규칙을 따르면 실제 코드를 사실상 전부 테스트하는 테스트 케이스가 나온다.

 

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

• 깨끗한 테스트 코드란? 가독성, 가독성, 가독성!!
• 테스트 코드는 실제 코드 못지않게 중요하다. 실제 코드 못지않게 깨끗하게 짜야한다.
• 코드에 유연성, 유지보수성, 재사용성을 제공하는 버팀목이 바로 단위 테스트이다.
• 테스트 케이스가 있으면 변경이 두렵지 않다.
• 테스트 코드가 지저분하면 코드를 변경하는 능력이 떨어지며 코드 구조를 개선하는 능력도 떨어진다.

2-1. 이중 표준

• 테스트 코드에 적용하는 표준과 실제 코드에 적용하는 표준은 다르다.
  • 단순성, 간결성, 표현력이 갖춰져야 하지만, 실제 코드만큼 효율적일 필요는 없다.

 

3. 테스트 당 assert 하나? 테스트 당 개념 하나!

• assert 문이 단 하나인 함수는 결론이 하나라서 코드를 빠르게 이해할 수 있다.
• 하지만, 그렇다고 테스트를 분리하면 중복되는 코드가 많아진다. 
• '단일 assert 문'은 좋은 지침이지만, 때로는 함수 하나에 여러 assert 문을 넣는 것이 더 나을 수도 있다.
  • assert 문 개수를 최대한 줄이는 것은 좋다.
• 잡다한 개념을 연속으로 테스트하는 긴 함수는 피해야 한다.
• 개념 당 assert 문 수를 최소로 줄여라! 테스트 함수 하나는 개념 하나만 테스트하라!

 

4. FIRST

• Fast
  • 테스트가 빠른 시간 내에 다 돌도록 하자
  • 테스트가 느리면 자주 돌릴 엄두를 내지 못한다.

• Isolated (Independent)
  • 좋은 단위 테스트는 다른 단위 테스트에 의존하지 않는다.
  • 각 테스트는 독립적으로, 그리고 어떤 순서로 실행해도 괜찮아야 한다.

• Repeatable
  • 좋은 테스트는 반복 가능해야 한다. 즉, 실행할 때마다 결과가 같아야 한다. 이를 위해 직접 통제할 수 없는 외부 환경에 있는 항목들과 격리시켜야 한다.
• Self-validating
  • 테스트는 bool 값으로 결과를 내야 한다. (성공 아니면 실패다.)
  • 테스트 스스로 성공과 실패를 가늠하도록 해야 한다. 
• Timely
  
  • 단위 테스트를 적시에 사용하자. 단위 테스트를 작성하는 습관을 가지자.
  • 실제 코드를 구현하기 직전에 구현하도록 하자.