TDD 법칙 세 가지

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

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

안정성 높이기

• 테스트 코드가 없으면 프로그램의 안정성을 검증할 수 없어져 결함율이 높아진다.
  
• 개발자는 변경을 주저하게 되고, 코드를 정리하지 않는다.
  
  

가독성 높이기

• 테스트는 유연성, 유지보수성, 재사용성을 제공한다.
  
• Build-Operate-Check 패턴 사용하기.
  
  • 테스트 자료를 만들고, 테스트 자료를 조작하고, 조작한 결과가 올바른지 확인한다.
    
    

도메인 특화 언어(DSL) 사용하기

• 테스트 코드에서 사용할 함수와 유틸리티를 인터페이스로 제공한다.
  
• 테스트를 구현하는 당사자와 나중에 테스트를 읽어볼 독자를 도와주는 테스트 언어가 된다.
  
  

이중 표준 사용하기

• 테스트 환경과 실제 환경을 구분한다. 실제 코드만큼 효율적일 필요는 없다.
  
  

개념 당 assert 하나

• 꼭 테스트당 assert 하나를 고집할 필요는 없다. 관련된 개념은 그룹화할 수 있다.
  
  • JUnit @Tag 사용하기.
    
• Template Method 패턴을 활용하여 가독성을 높인다.
  
  • JUnit @Before, @After 등 사용하기.
    
    

F.I.R.S.T

깨끗한 테스트는 다음 다섯 가지 규칙을 따른다.

1. 빠르게(Fast): 테스트는 빨라야 한다. 테스트가 느리면 자주 돌릴 엄두를 못 낸다.
   
2. 독립적으로(Independent): 테스트가 서로 의존하면 안 된다. 테스트가 실행 순서에 따라 다른 결과를 도출하면 안된다.
   
3. 반복가능하게(Repeatable): 테스트는 어떤 환경에서도 반복 가능해야 한다. 실제 환경, QA 환경, 네트워크가 연결되지 않은 환경 등.
   
4. 자가검증하는(Self-Validating): 테스트는 성공하거나 실패해야 한다. 통과 여부를 알리고 로그 파일을 읽게 만들어서는 안된다.
   
5. 적시에(Timely): 단위 테스트는 실제 코드를 구현하기 직전에 구현한다.