애자일과 TDD덕택에 단위테스트를 자동화하는 프로그래머들이 많아졌으며 점점 늘어나는 추세다. 하지만, 테스트를 추가하려고 급하게 서두르는 와중에 제대로 된 테스트 케이스를 작성해야 한다는 더 중요하고 미묘한 사실을 놓치고 있다.
TDD법칙 세 가지
첫째 법칙 : 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
둘째 법칙 : 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
셋째 법칙 : 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.
실패하는 테스트 추가 → 최소한의 코딩을 통한 테스트 통과 → 테스트 통과를 유지하면서 구조/설계 개선
깨끗한 테스트 코드 유지하기
테스트 코드는 구현에 신경쓰지 않고 조금 지저분해도 빨리 개발하는게 좋다고 생각하는 프로그래머들이 존재한다. 그러나 실제 코드가 진화하면 테스트코드도 진화해야 하므로, 대충 짠 테스트코드는 개발의 발목을 잡는 주요 원인이 된다.
대충짠 테스트코드를 비난하고, 테스트코드를 제거하고 나면 결함율이 높아지고, 변경을 주저하면서 코드를 정리하지 않게 된다. 결국 코드는 망가지고 서비스는 망할 수 밖에 없다. 결국 깨끗한 테스트코드만이 정답이다.
테스트는 유연성, 유지보수성, 재사용성을 제공한다.
제대로된 단위테스트는 변경에 대한 정상여부를 알려주므로, 지속적으로 코드를 개선해 나갈 수 있는 힘을 제공한다.
깨끗한 테스트 코드는 무엇보다 가독성이 중요하다. 가독성을 높이려면 명료성, 단순성, 풍부한 표현력이 필요하다.
테스트코드는 Given When Then형태로 정리하고, 중복코드는 별도 함수로 빼내서 의미를 빨리 이해할 수 있게 구현한다.
테스트코드는 단순하고, 간결하고, 표현력이 풍부해야 하지만, 실제 코드만큼 효율적일 필요는 없다(이중 표준)
StringBuffer 대신 String을 붙이거나, 축약형 함수를 쓰는 등 실제 코드에서는 좋지않은 방법도 테스트코드에서는 적절할 수 있다.
테스트 함수마다 하나의 개념만 테스트하라
테스트당 assert문은 최소로 줄이고, 하나의 개념만 테스트하라.
여러 개념을 테스트하면, 테스트가 복잡해지며, 테스트에 누락이 발생하기 쉽다.
F.I.R.S.T
Fast : 테스트는 빨라야 한다.
Independent : 각 테스트는 의존하지 않고, 독립적으로 수행할 수 있어야 한다.
Repeatable : 어떤 환경에서도 반복 가능해야 한다. 환경을 타면 테스트를 제외할 변명이 생긴다.
Self-Validating : 테스트 자체로 성공/실패를 판별가능해야 한다, 별도로 로그내용 등을 통해 통과여부를 알아서는 안됨.
Timely : 실제 코드를 구현하기 직전에 구현. 테스트 코드를 늦게 개발하면, 테스트가 불가능하도록 실제 코드가 설계된다.
결론
테스트 코드가 방치되어 망가지면 실제 코드도 망가진다. 테스트 코드를 깨끗하게 유지하라.