가독성

이승한·2020년 1월 8일
0
  1. 단언문과 관련된 테스트 냄새
  2. 제품 코드에 흩뿌려진 정보와 관련된 테스트 냄새
  3. 과하거나 불필요한 세부 정보와 관련된 테스트 냄새
  • 테스트란 코드에 바라는 동작과 가정을 프로그래머식으로 표현한 것, 읽은 프로그래머는 코드가 해야 할 일을 이해하고 실제로 한 일이 무엇인지 말할 수 있어야 한다.

기본타입 단언

  • 단얼하려는 이유나 의도가 의미를 알 수 없는 단어나 숫자에 가려진 상황
  • 검새해야 할 동작보다 더 기초적인 요소에 집착하는 것
  • 개선방법
    • API 추상화 수준을 다시 확인한다.
    • !=, == 등 비교문을 사용하는 단언문의 추상화 수준을 올린다.

광역 단언

  • 테스트가 실패하는 이유는 오직 하나뿐 이어야 한다. (단일 책임의 원칙)
  • 본래 의도가 광활한 검증 범위에 묻혀 희석된다.
  • 검사하려는 동작의 아주 작은 하나까지도 놓치지 않게 집착.
  • 조그만 변화만 생겨도 테스트가 실패한다.
  • 단언문 대부분이 실패의 원인과 아무런 관련도 없을 것이다.
  • 테스트의 의도와 핵심을 파악하는데 방해가 된다.
  • 개선방법
    • 본질과 관련없는 세부냉용을 찾아 테스트에서 제거한다.
    • 세부 정보를 숨기고 한가지 일에만 충실하게 한다.
    • 핵심을 빠르게 파악할 수 있는 테스트를 만들어라.

비트 단언

  • 의미 파악을 방해 하기 쉽다.
  • 부울 연산자로 변환하여 가독성을 높힌다.

부차적 세부 정보

  • 읽기 쉬운 코드는 읽는 이에게 그 의도와 목적과 의미를 빠르고 정화하게 보여준다.
  • 부차적 세부정보 : 테스트 코드에 부수적인 정보 많은것
  • 테스트 하려는 일이 진짜 명백한가? 당연하다는 말이 선뜻 나오지 않는다면 아직 다 끝난게 아니다.
  • 서술형 메서드 이름으로 충분하지 않다.
  • 개선 방법 : 테스트의 핵심은 정면 한가운데 있어야 한다.
    • 핵심이 아닌 설정은 Private 이나 셋업 메서드로 추출
    • 적절한 인자와 서술형 이름을 사용하라.
    • 한 메서드 안에서는 모두 같은 수준으로 추상화 하라.

다중 인격

  • 여러개의 테스트 목적인 한 개의 테스트 메서드를 공유한다.
  • 하나의 메서드는 오직 한 가지만 똑바로 검사해야 한다.
  • 큰 시나리오만 떼어내도 테스트 메서드에 서술적인 이름 짓기가 수월하다.
  • 읽기 쉬운 코드는 목적을 명확히 전달한다. 실수했을 때 잘못된 곳을 더 정확하게 꼬집어준다. 담당하는 영역이 좁아졌기 때문이다.
  • 혼란스러운 코드는 세부 정보와 큰 그림 모두를 감춰 버린다.

쪼개진 논리

  • 작게 나누면 가독성과 유지보수성이 크게 좋아진다. 하지만 너무 나누면 변질된다.
    • 무작정 나누기 보다는 같은 속성을 공유하는 의미있는 조각이 어디까지인지 신경쓰면서 나눠주어야 한다.
  • 코드를 읽을 때 이리저리 오가지 않도록 조심하라.
  • 흩어진 코드를 분석하느라 프로그래머의 인지 부하를 가중 시키고 의미와 의도를 파악하기 어렵게 한다.
  • 테스트 논리나 데이터를 독립 파일로 두는 것은 합리적 이기도 하지만 일반적으로는 메서드에 함께 두는 방법을 찾는게 합리적이다.
  • 데이터나 로직을 통합하는 기준 (데이터 파일을 별도로 두는건 비용이 크다)
    1. 짧다면 통합하라.
    2. 길다면 팩토리 메소드나 데이터 생성기를 만들어라.
    3. 이것 마저 쉽지 않다면 그냥 독립 파일로 남겨둬라. (최후의 보루)

매직 넘버

  • 지역 변수나 서술형 이름ㅇ의 상수로 대체하여 의미 전달력을 키워줘야 한다.
  • 간결함 보다는 가독성을 우선해야 할 때도 있다.

셋업 설교

  • 테스트 메서드는 본질만을 담아 간결하게 유지하고 나머지 세부내용은 도우미 메서드로 추출하는 하면 상당한 량의 코드를 세업 메서드로 옮기기도 한다. 지저분한 셋업 메서드를 심각하게 받아들이지 않곤 한다.
  • 픽스처 - 테스트가 실행하는 어떤 것 이다. 시스템 속성, 정의된 상수, 셋업 메서드가 초기화환 Private 멤버 등
  • 부차적인 상세정보 냄새 일종이다. 개선 방법은 아래와 같다.
    • 셋업에서 핵심을 제외한 정보는 Private method 로 추출
    • 알맞은 서술적 이름을 사용
    • 셋업 내의 추상화 수준을 통일
  • 정리해보면 줄 수는 오히려 늘기도 하지만 더 명확해 지니 손해는 아니다.

과잉보호 테스트

  • NPE 를 지겹도록 마주하다보니, 많은 프로그래머는 메서드 시작 부분에 널 검사 등의 방버 코드를 넣어 자신을 보호하는 습관을 길렀다.
  • 과잉보호 테스트는 테스트의 성패를 결정짓는 진짜배기 단언문에 도달하기 전까지 불필요한 중간 단계 단언문이 많이 등장하는 것을 말한다.
  • 명확할수록 더 조힉ㄴ 하지만, 시시콜콜한 정보까지 모두 명확하게 해놓으면 후임 프로그래머 입장에서는 더 혼란스러울 뿐이다.

요약

이들은 테스트 가독성을 떨어뜨리고, 테스트에서 벌어지는 일이나 핵심 의도를 파악하기 어렵게 한다.

profile
software develop engineer

0개의 댓글