하지만 우리 분야에 테스트를 추가하려고 급하게 서두르는 와중에 많은 프로그래머들이 제대로 된 테스트 케이스를 작성해야 한다는 좀 더 미묘한 (그리고 더욱 중요한) 사실을 놓쳐버렸다.
TDD 법칙 세 가지
👉 실제 코드를 짜기 전, 단위 테스트 부터 짜라고 요구하는 사실! 하지만 이것은 빙산의 일각에 불과하다.
- 세 가지의 TDD 법칙
이 규칙을 따르면 30초 주기로 개발과 테스트가 묶임
첫째 법칙 : 실패하는 단위 테스트를 작헝할 때까지 실제 코드 작성 ✕
둘째 법칙 : 컴파일은 실패하지 않으면서 실행이 실패하는 정도만 단위 테스트 작성
* 셋째 법칙 : 현재 실패하는 테스트를 통과할 정도로만 실제 코드 작성 - 방대한 테스트 코드는 심각한 관리 문제를 유발!!
깨끗한 코드 유지하기
👉 테스트를 안 하는 것보다 지저분한 테스트 코드를 내 놓는 것이 더 나쁘다! 테스트 코드는 실제 코드 못지 않게 중요하다.
- 테스트는 유연성, 유지보수성 재사용성을 제공한다.
- 이를 제공하는 버팀목은 단위 테스트
- 지저분한 테스트 코드는 변경/개선 능력↓
- 지저분한 테스트 코드 → 지저분한 실제 코드
깨끗한 테스트 코드
👉 포인트는 가독성
-
테스트 코드에서 가독성은 더더욱 중요!
-
명료성, 단순성, 풍부한 표현력, 잡음 제거
-
도메인에 특화된 테스트 언어 (DSL)
- 🔎 특정 영역의 문제 해결에는 그 영역에 맞는 특화된 도구를 사용하자는 취지
- API 위에 함수와 유틸리티를 구현한 후 이를 사용 → 테스트 코드 작성 용이
- API를 끊임없이 리팩터링하는 것이 필요
-
이중 표준
- 🔎 실제 환경에서는 절대로 안 되지만 테스트 환경에서는 전혀 문제가 없다는, 말 그대로 '이중 표준'
- 테스트 코드는 깨끗해야 하지만 실제 코드만큼 효율적일 필요 ✕
테스트 당 assert 하나
👉 함수마다 assert 문은 단 하나만 사용하자
- 병합하기 불합리하다면 쪼개어 각자가 assert 문을 수행하도록 하자.
- 테스트를 분리하면 중복되는 코드가 많아지는데, 이는 TEMPLATE METHOD 패턴으로 해결하자.
- 참고 : https://kimseunghyun-bg.github.io/programming/oop/template_method_pattern/
- 배보다 배꼽이 더 큰 코드가 되기도 하지만, 이득이 훨씬 더 크다!
- 테스트 당 개념 하나
- 테스트 함수마다 한 개념만 테스트
- 사실, assert 문이 하나씩만 있는 것보다 더 신경써야하는 부분이다.
F.I.R.S.T
👉 깨끗한 테스트의 5가지 규칙
- Fast : 테스트는 자주 돌릴 수 있도록 빨라야 한다.
- Independent : 각 테스트는 어떤 순서로 테스트 해도 상관 없도록 독립적이여야 한다.
- Repeatable : 테스트는 변명할 수 없도록 어떤 환경에서도 반복이 가능해야 한다.
- Self-Validating : 테스트는 부울 값으로 결과를 내어 성공/실패로 나타내야 한다.
- Timely : 테스트는 적시에 작성하여 테스트를 염두해두며 코드를 설계할 수 있도록 한다.
결론
👉 깨끗한 테스트 코드는 이 내용이 전부가 아니다. 그만큼 중요하며 많은 공부가 필요하다!!
- 어쩌면 테스트 코드는 실제 코드보다 중요하다.
- 지속적으로 테스트 코드를 깨끗하게 관리하자.
인상 깊었던...
'지저분해도 빨리'가 주제였다. 변수 이름은 싱경 쓸 필요가 없었고, 테스트 함수는 간결하거나 서술적일 필요가 없었고, 테스트 코드는 잘 설계하거나 주의해서 분리할 필요가 없었다.
테스트 코드가 방치되어 망가지면 실제 코드도 망가진다.
노력하는 초보 개발자