해당 포스트는 Clean Code의 내용을 참고하여 작성되었습니다.
TDD 법칙 세가지
- 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다
- 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다
- 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다
단위 테스트
단위 테스트는 코드에 유연성, 유지보수성, 재사용성을 제공한다. 깨끗한 테스트 코드를 만들려면 세가지가 필요하다. 가독성 가독성 가독성. 가독성을 높이려면 여느 코드와 마찬가지로 명료성, 단순성, 풍부한 표현력이 필요하다. 최소의 표현으로 많은 것을 나타내야 한다. 테스트 코드는 읽는 사람에게 온갖 잡다하고 세세한 코드에 주눅들고 헷갈릴 필요 없이 코드가 수행하는 기능을 재빨리 이해할 수 있도록 작성해야 한다.
이중 표준
임베디드 시스템에 테스트 코드를 작성할 때 일이다. StringBuffer가 보기 흉하다고 해서 사용하지 않았다. 임베디드 시스템은 컴퓨터 자원과 메모리가 제한적일 가능성이 높지만 테스트 환경은 자원이 제한적일 가능성이 낮기 때문이다. 이것이 이중 표준의 본질이다. 실제 환경에서는 절대로 안 되지만 테스트 환경에서는 전혀 문제없는 방식이 있다. 대게 메모리나 CPU 효율과 관련있는 경우다. 코드의 깨끗함과는 철저히 무관하다.
테스트당 개념 하나
이것저것 잡다한 개념을 연속으로 테스트하는 긴 함수는 피한다. 한 테스트 안에서 독자적인 개념 여러개를 수행하면 이는 분리해야 마땅하다. 여러 개념을 한 함수로 몰아넣으면 독자가 각 절이 거기에 존재하는 이유와 각 절이 테스트하는 개념을 모두 이해해야 한다. 그러므로 가장 좋은 규칙은 개념 당 assert 문 수를 최소로 줄여라와 테스트 함수 하나는 개념 하나만 테스트 하라이다.
F.I.R.S.T
깨끗한 테스트는 다음 다섯가지 규칙이 있다.
- Fast : 테스트는 빨라야한다.
- Independent : 각 테스트는 서로 의존하면 안된다. 한 테스트가 다음 테스트가 실행될 환경을 준비해서는 안된다.
- Repeatable : 테스트는 어떤 환경에서도 반복 가능해야한다. 실제 환경, QA 환경, 버스를 타고 집에 가는 길에 사용하는 노트북 환경에서도 돌아가야한다.
- Self-Validating : 테스트는 bool 값으로 결과를 내야 한다. 성공 아니면 실패다. 통과 여부를 알려고 로그 파일을 읽게 만들어서는 안된다.
- Timely : 테스트는 적시에 작성해야한다. 단위 테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현한다. 실제 코드를 구현한 다음에 테스트 코드를 만들면 실제 코드가 테스트하기 어렵다는 사실을 발견할지도 모른다.