Clean Code - 3

단위 테스트

테스트는 많은 개발자들에게 애증의 관계로 여겨집니다. 테스트 코드를 작성하는 것도 그렇지만, 한 번 작성한 테스트들도 유지보수의 대상이 되어 피쳐가 수정될 때 마다 테스트도 함께 수정해야하기 때문이죠. 뭔가 개발자가 스스로 일거리를 늘리는 느낌이 듭니다. 하지만 밥 아저씨는 이건 테스트의 문제가 아니라 테스트 코드(케이스)를 아무렇게나 작성한 개발자(혹은 팀)의 잘못이라고 이야기 합니다.

 

깨끗한 테스트 코드 유지하기

테스트 코드는 내가 작성한 코드와 기존의 코드를 신뢰할 수 있도록 도와줍니다. 테스트가 되고 있지 않은 코드는 잠재적 버그이기 때문이지요. 이런 의미에서 깨끗한 테스트는 유연성, 유지보수성, 재사용성을 제공한다고 밥 아저씨는 이야기 합니다. 그렇다면 깨끗한 테스트 코드는 무엇이고 어떻게 만들 수 있을까요?

 

• 높은 가독성
  • 테스트는 명료하면서도 단순하고 풍부한 표현력을 가지고 있어야 합니다. 이는 실제 동작하는 코드와 일맥상통하는 부분인 것 같습니다. 테스트 코드도 결국은 유지보수의 대상이기 때문에 가독성이 높고 명료하게 작성하여 테스트의 의도와 목적, 테스트 하고자 하는 바를 파악하기 쉽도록 해야 합니다. given-when-then의 관례를 이용한는 것도 도움이 될 것 같습니다.
• 테스트당 개념 하나
  • 하나의 테스트 함수는 한가지 만을 테스트 해야 합니다. 테스트가 단순할 수록 이해하기 쉽기 때문입니다. 밥 아저씨는 하나의 테스트 함수에 하나의 assert만을 사용할 것을 권고하고 있습니다.
• F.I.R.S.T
  • Fast : 테스트는 빠르게 돌아야 합니다. 테스트 실행 속도가 늦어질 수록 테스트 자체에 부담을 느끼게 되어 테스트 주기가 길어지게 되고, 문제를 일찍 파악하기 어려워집니다.
  • Independent : 각 테스트는 독립적이어야 합니다. 테스트 사이에 의존성이 생기게 되면 테스트 실패의 원인을 찾기 어려워 지고 문제를 찾기 어렵게 만듭니다.
  • Repeatable : 테스트는 어떤 환경에서도 반복 가능해야 합니다. 예를들어 테스트가 네트워크 환경에 의존하고 있다면 인터넷을 사용하기 어려운 환경에서는 테스트가 불가능해질 것입니다. 테스트가 돌아가지 않는 환경이 하나라도 있다면 그 존재 만으로도 문제가 되지만 테스트가 실패한 이유를 둘러댈 변경거리가 생기게 됩니다.
  • Self-Validating : 테스트 결과는 성공 혹은 실패 둘 중하나로만 결정되어야 합니다. 만약 테스트가 어떤 로그를 남기고 이걸 사람이 직접 확인해야 한다면 성공과 실패의 반단은 주관적이 되며, 일거리만 늘어나게 됩니다. 따라서 테스트는 스스로 성공여부를 판단할 수 있도록 만을어져야 합니다.
  • Timely : 테스트는 적시에 작성되어야 합니다. 그리고 이 적시는 실제 코드를 구현하기 직전을 말합니다. 만약 실제 코드가 testable하지 않다면 testabillity를 높이기 위해 수정의 과정이 필요하게 될 수도 있고, 심한경우 테스트가 불가능 할 수도 있습니다.

 

클래스

밥 아저씨는 깨끗한(?) 클래스에 관해 여러 예시로 여러 이야기를 하지만 결국 이야기 하는 것은 한가지 입니다. 'SRP를 지킬 것' SRP는 한 하나의 이유에서만 수정되어야 한다는 원칙으로서  하나의 책임만을 가지고 있어야 한다고도 이야기 하는 원칙입니다. 단순히 메소드의 갯수나 길이에 대한 문제가 아닌 책임과 응집도의 문제 입니다.

 

만약 클래스가 여러 책임을 가지고 있다면, 즉 클래스를 변경해야 하는 이유가 여러개 일 경우 혹은 응집도가 낮아질 경우 해당 클래스는 여러개의 작은 클래스들로 나누어져야 합니다. 만약 하나의 메소드가 너무 비대해져 있다면 여러개의 작은 메소드들로 나눕니다. 이렇게 메소드를 나누는 과정에서 응집도가 낮아진다면, 클래스를 나눕니다.