단위 테스트

TDD 법칙 세 가지

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

 

깨끗한 테스트 케이스 유지하기 

테스트 코드도 프로덕션 코드만큼 중요하다

테스트 코드를 지저분하게 작성하는 것은 테스트를 하지 않는 것보다 더 나쁠 수도 있다. 프로덕션 코드가 진화하면 테스트 코드도 함께 진화해야 하는데, 유지보수하기 어려운 테스트 코드는 결국 방치되거나 삭제될 가능성이 높다.

테스트 코드는 단순히 버그를 찾기 위한 것이 아니라, 코드의 유연성, 유지보수성, 재사용성을 높이는 데 중요한 역할을 한다. 테스트가 잘 갖춰져 있다면 코드 변경이 두렵지 않고, 오히려 안심할 수 있다.

 

 

깨끗한 테스트 코드 작성 방법

1. 가독성이 가장 중요하다

테스트 코드는 실제 코드보다 가독성이 더 중요할 수도 있다. 테스트의 목적이 명확해야 하며, 이를 위해 명료성, 단순성, 풍부한 표현력이 필요하다.

잡다하고 세세한 코드를 없애고, 중복된 부분을 메서드로 분리하여 가독성을 높이자.

이를 위해 Build-Operate-Check 패턴을 적용할 수 있다. 예를 들어, 나 같은 경우는 테스트 데이터를 생성하는 부분에서 중복이 많이 발생했는데, 이 코드를 메서드를 추출하는 방식으로, 테스트를 보기 좋게 만들 수 있다.

• Build: 테스트 데이터 생성
• Operate: 테스트 데이터 조작
• Check: 결과 검증

2. 테스트 당 assert 하나?

assert를 하나만 사용하면 테스트의 결론이 명확해지지만, 코드 중복이 늘어날 수 있다. 이를 해결하기 위해 TEMPLATE METHOD 패턴을 사용할 수 있다.

• given, when 부분을 부모 클래스에 두고, then 부분을 자식 클래스에서 구현하는 방법
• @Before 메서드에서 given/when 부분을 설정하고, @Test 메서드에서 then을 검증하는 방법

하지만 너무 복잡해질 수 있다.

'테스트 당 assert 하나를 쓰자'가 아닌 '개념당 assert 문을 최소로 줄이고, 테스트 함수마다 한 개념만 테스트하자'가 더 낫다.

 

F.I.R.S.T - 깨끗한 테스트를 위한 5가지 원칙

1. FAST (빠르게)
   • 테스트는 빠르게 실행되어야 한다.
   • 느린 테스트는 자주 실행하기 어려워지고, 결국 코드 품질이 저하될 수 있다.
2. INDEPENDENT (독립적으로)
   • 각 테스트는 서로 독립적이어야 하며, 실행 순서에 영향을 받지 않아야 한다.
3. REPEATABLE (반복 가능하게)
   • 어떤 환경에서도 동일한 결과가 나와야 한다.
4. SELF-VALIDATING (자가 검증 가능하게)
   • 테스트 결과는 성공/실패로 명확하게 나와야 하며, 로그를 읽거나 수작업으로 비교해야 하는 경우는 지양해야 한다.
5. TIMELY (적시에 작성하기)
   • 테스트 코드는 실제 코드를 작성하기 직전에 만들어야 한다.
   • 실제 코드 작성 후 테스트를 만들면, 테스트하기 어렵게 설계될 가능성이 높다.

 

TDD를 직접 실천해 보고 관련 서적을 읽어보니, "아, 그랬었지!" 하면서 공감되는 부분이 많았다. 단순히 개념으로만 접할 때는 이해하기 어려웠던 원칙들이, 직접 적용해보니 왜 필요한지 몸소 깨닫게 되었다.

테스트 코드가 단순한 보조 수단이 아니라, 코드의 품질을 높이고 변경을 두려워하지 않도록 도와주는 중요한 도구라는 점을 다시 한번 실감하게 되었다.