[클린코드 리뷰] 5. TDD, 테스트 코드를 깨끗하게 유지하자.

 

 작은 회사는 TDD(Test Driven Development / 테스트 주도 개발)를 못한다. 그 회사들 중 절반은 TDD가 뭔지도 모를 것이고, 나머지 절반은 알아도 여력이 없어서 못한다고 말하리라. 하지만 여력이 없다는 핑계로 테스트케이스를 만들지 않은 대가는 결국 부메랑처럼 돌아온다. 그 시스템의 수정은 항상 불안하며 버그를 발생하게 한다. 나 역시 그랬다.

 

 예를들어 기존의 입력폼에 간단한 항목 하나를 추가한다고 해보자. 뷰페이지와 데이터베이스에 추가하는 건 간단하다. 그리고 생각한다. '사용자 정보가 노출되는 페이지, 마이페이지, 관리자 페이지의 목록들과 팝업창, 그리고 어떤 함수에 들어가서 계산이 되는 곳, 혹은 통계페이지, 혹은 리포트, 그리고 엑셀, 워드 등등.. 오케이 다 추가했다!!' 그리고 역시나 버그가 발생한다. 그리고 말한다 '제 자리에서는 잘 되는데요?' 혹은 클라이언트에게 통보한다.

 

'지금 시점에서 더 이상의 수정은 위험합니다. 버그가 발생할 수 있습니다.'

 

 사람은 누구나 실수를 할수있으며, 개발자 역시 사람이다. 이렇듯 시스템의 규모가 커질수록 개발자는 자신을 믿어선 안된다. 차라리 의심하는 게 낫다. 

 

 

테스트는 유연성, 유지보수성, 재사용성을 제공한다

 테스트 케이스가 없으면 실제 코드를 유연하게 만드는 버팀목도 사라진다. 코드에 유연성, 유지보수성, 재사용성을 제공하는 버팀목이 바로 단위테스트다. 이유는 단순하다. 테스트 케이스가 있으면 변경이 두렵지 않으니까. 테스트 케이스가 없다면 모든 변경이 잠정적인 버그다. 아키텍쳐가 아무리 유연하더라도, 설계를 아무리 잘 나눴더라도, 테스트 케이스가 없으면 개발자는 변경을 주저한다. 버그가 숨어들까 두렵기 때문이다.

 하지만 테스트 케이스가 있다면 공포는 사실상 사라진다. 테스트 커버리지가 높을수록 공포는 줄어든다. 아키텍쳐가 부실한 코드나 설계가 모호하고 엉망인 코드라도, 별다른 우려 없이 변경할 수 있다. 아니, 오히려 안심하고 아키텍처와 설계를 개선할 수 있다.

 테스트는 유연성, 유지보수성, 재사용성을 제공한다. 테스트케이스가 있으면 변경이 쉬워지기 때문이다.

 

 

 

TDD 법칙 세가지

 TDD가 실제 코드를 짜기 전에 단위 테스트부터 짜라고 요구한다는 사실을 모르는 사람은 없으리라. 하지만 이 규칙은 빙산의 일각에 불과하다. 다음 세 가지 법칙을 살펴보자.

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

 이렇게 하면 테스트 코드와 실제 코드가 함께 나올뿐더러 테스트 코드가 실제 코드보다 불과 몇 초 전에 나온다. 이렇게 일하면 매일 수십 개, 매달 수백 개, 매년 수천 개에 달하는 테스트 케이스가 나온다. 이렇게 일하면 실제 코드를 사실상 전부 테스트하는 테스트 케이스가 나온다. 

 

 

 

깨끗한 테스트의 다섯 가지 규칙 F.I.R.S.T

Fast, 빠르게
 테스트는 빨라야 한다. 테스트가 느리면 자주 돌릴 엄두를 못 낸다. 자주 돌리지 않으면 초반에 문제를 찾아내 고치지 못한다. 결국 코드 품질이 망가지기 시작한다.

Independent, 독립적으로
 각 테스트는 서로 의존하면 안 된다. 각 테스트는 독립적으로 그리고 어떤 순서로 실행해도 괜찮아야 한다.

Repeatable, 반복가능하게
 테스트는 어떤 환경에서도 반복 가능해야 한다. 테스트가 돌아가지 않는 환경이 하나라도 있다면 테스트가 실패한 이유를 둘러댈 변명이 생긴다.

Self-Validating, 자가검증하는
 테스트는 부울(bool) 값으로 결과를 내야 한다. 성공 아니면 실패다.

Timely, 적시에
 단위 테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현한다. 실제 코드를 구현한 다음에 테스트 코드를 만들면 실제 코드가 테스트하기 어렵다는 사실을 발견할지도 모른다. 어떤 실제 코드는 테스트하기 너무 어렵다고 판명 날지 모른다.

 

 

 

결론

 테스트 코드는 실제 코드만큼이나 프로젝트 건강에 중요하다. 어쩌면 실제 코드보다 더 중요할지도 모르겠다. 테스트 코드는 실제 코드의 유연성, 유지보수성, 재사용성을 보존하고 강화하기 때문이다. 그러므로 테스트 코드는 지속적으로 깨끗하게 관리하자. 표현력을 높이고 간결하게 정리하자. 테스트 코드가 망가지면 실제 코드도 망가진다.

 

 

 

 

 

출처 : 클린코드(애자일 소프트웨어 장인 정신), 로버트 C.마틴