[테스트 주도 개발로 배우는 객체지향 설계와 실천] 21장 테스트 가독성

21장 테스트 가독성

테스트 가독성을 향상 시키기 위한 규칙들

• TDD가 지속 가능하려면 테스트가 코드의 작동 방식을 검증하는 것 이상을 해야만 한다.
• 테스트는 행위를 명확하게 표현하기도 해야 한다. = 테스트의 가독성이 중요한 이유

• 테스트 코드는 제품에서 하는 일이 무엇인지 반드시 기술해야 한다,

  • 테스트 코드가 예상 되는 결과의 예제로 사용하는 값에 관해서는 구체적이지만 해당 코드가 동작하는 방식에 관해서는 추상적인 경향이 있기 때문.
  • 테스트 코드는 의존성 사슬의 끝에 위치하므로 대상 코드의 의도를 표현하는 것이 다른 객체망의 일부를 구성하는 일보다 중요하다.

테스트의 이름은 기능을 기술한다.

• 테스트의 이름은 개발자가 현재 테스트 중인 것이 무엇이고 대상 객체가 어떻게 행동해야 할지에 대한 첫 번째 단서를 제시해야 한다.

  • 다양한 상황에서 객체가 무슨 일을 하고 메서드 용도가 무엇인지 알 필요가 있다.

• 대상 객체에서 제공하는 기능 측면에서 테스트 이름을 짓는 것

  • Test dox 관례 -> 개발자가 대상 객체가 하는 일을 중심으로 생각하게끔 독려함.

정규 테스트 구조

• 테스트를 표준 형태로 작성하면 이해하기 쉽다.
• 테스트를 표준 형태로 작성하기 어렵다 => 코드가 너무 복잡하거나 아이디어를 그다지 명확하게 하지 않았음을 암시
• 준비 : 대상 코드가 실행될 환경에 해당하는 테스트의 콘텍스트를 마련한다.
• 실행 : 대상 코드를 호출해 테스트된 행위를 촉발한다.
• 검증 : 해당 행위에서 예상할 수 있는 가시적인 효과를 검사한다.
• 정리 : 다른 테스트에 손상을 입힐 수도 있을 잔존 상태를 정리한다.

테스트 코드의 능률화

• 테스트 코드를 비롯해 모든 코드는 '어떻게' 보다 '무엇'을 강조해야 한다.

  • 메서드에 구현 세부 사항이 많이 포함될수록 해당 메서드를 읽는 사람은 무엇이 중요한지 이해하기 더 어려워진다.
• 테스트가 대상 코드가 하는 일을 서술하게 해서 대상 코드의 흐름을 파악할 수 있을 정보로 리팩터링 하는 것

단정과 예상구문

• 의도를 담아서!

리터럴과 변수

• 테스트 코드는 제품 코드에 비해 구체적인데, 이것은 테스트 코드에 리터럴 값이 더 많다는 의미

• 설명이 없는 리터럴 값은 이해하기 어렵다.

  • 리터럴 값을 변수나 상수에 할당하고, 그것들의 기능을 기술하는 이름을 부여해야 한다.
• 변수에 이름을 부여해 이러한 값이다 객체가 테스트에서 수행하는 역할과 그것들의 대상 객체와의 관계를 보여준다.