Testable code - 요약

viiviii·2021년 10월 22일
0

주의: 이 포스팅은 내가 자주 보기 위해 원글을 엄청나게 요약해놓은 정리본이다.

원 글인 myner님의 Testable code 시리즈와 영어 원문에서는 상세한 Warning signs과 이유, 해결 방법, sample code가 있으니 꼭 봐야 함

원문 링크

Testable Code 1 - feat. constructor
Testable Code 2 - feat. collaborators
Testable Code 3 - feat. static
Testable Code 마지막 - feat. SRP
원문- Guide: Writing Testable Code


TODO

  • SRP 원칙을 지켜라
    • 너무 많은 일을 하는 생성자를 주의해라
    • 너무 많은 일을 하는 클래스를 주의해라
    • 레거시일 경우 새로운 클래스부터라도 SRP를 지켜서 만들어라
  • 디미터 법칙을 지켜라
    • 직접 찾지 말고, 실제 사용될 객체를 주입받아라
    • 낯선 자에게 말하지 마라
  • API의 의존성을 명확히 나타내라
    • 메서드 시그니처나 생성자에 표현되어야 함
    • Hidden interactions을 피할 것
  • Dependency Injection is your Friend
    • collaborator를 직접 생성하지 말고 주입받아라
  • static, global state, singleton 사용을 멀리해라

Warning signs

  • 클래스
    • 생성자가 필드 할당 외에 다른 하는 일이 있는 경우
    • 초기화 블럭을 사용한 경우
    • 클래스 이름을 짓기 어렵거나, 모호한 단어가 어울리는 경우
    • 클래스가 하는 일을 표현할 때 AND가 들어가는 경우
    • 클래스에 일부 메서드에서만 사용되는 필드가 있는 경우
    • 너무 많은 collaborators나 무능한 collaborator가 존재하는 경우
  • 메서드
    • 전달되는 객체가 직접 사용되지 않는 경우
    • getter 메서드의 호출 체인이 여러 번 발생하는 경우
    • 광범위한 이름의 객체와 상호 작용하는 경우 (ex: context)
    • public API에 숨겨진 상호작용이 있는 경우
  • 테스트
    • 객체의 인스턴스화 및 테스트 작성이 복잡하고 어려운 경우
  • 새로운 팀원이 클래스를 읽었을 때 빠르게 이해하기 어려운 경우

추가로

  • 코드를 작성하는 동안 객체를 테스트하기 얼마나 어려운지 항상 생각해라
  • 생성자에서 collaborators를 초기화하지 말고, 초기화가 완료된 collaborators를 생성자로 받아라
  • 단일 책임에 대한 동작을 캡슐화하는건 좋지만, 책임간의 상호작용을 캡슐화하지 마라

잊지 말자 SRP, 디미터법칙, DI

profile
우리는 기대하는 수준까지 올라가는게 아니라, 훈련한 수준까지 떨어진다

0개의 댓글