TDD 법칙 세가지
- 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
- 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
- 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.
깨끗한 테스트 코드 유지하기
- 지저분한 테스트 코드는 테스트를 안하는 것보다 못하다.
- 테스트 코드는 실제 코드 못지 않게 중요하다.
- 테스트는 유연성, 유지보수성, 재사용성을 제공한다
- 테스트 케이스가 없다면 모든 변경이 잠정적인 버그다.
- 테스트 코드가 지저분하면 코드를 변경하는 능력이 떨어지며 코드 구조를 개선하는 능력도 떨어진다.
깨끗한 테스트 코드
- 가독성
- BUILD-OPERATE-CHECK 패턴:
첫 부분은 테스트 자료를 만든다.
두 번째 부분은 테스트 자료를 조작하며,
세 번째 부분은 조작한 결과가 올바른지 확인한다.
이중 표준
- 실제 환경에서는 절대로 안 되지만 테스트 환경에서는 전혀 문제없는 방식이 있다. 대개 메모리나 CPU 효율과 관련 있는 경우. 코드의 깨끗함과는 철저히 무관하다.
테스트당 assert 하나
- Junit으로 테스트 코드를 짤 때는 함수마다 assert 문을 단 하나만 사용해야 한다.
결론이 하나라서 코드를 이해하기 쉽고 빠르다. - 하지만 코드의 중복이 많다면 함수 하나에 여러 assert문을 넣기도 한다. 단 assert 문 개수는 최대한 줄여야 좋다.
-> 테스트 함수마다 한 개념만 테스트하라
F.I.R.S.T
- Fast 빠르게: 테스트는 빨라야 한다.
- Independent 독립적으로: 각 테스트는 서로 의존하면 안된다.
- Repeatable 반복가능하게: 테스트는 어떤 환경에서도 반복 가능해야 한다.
- Self-Validating 자가검증하는: 테스트는 bool 값으로 결과를 내야 한다.
- Timely 적시에: 테스트는 적시에 작성해야 한다.
yesjm's second brain