- 단언문과 관련된 테스트 냄새
- 제품 코드에 흩뿌려진 정보와 관련된 테스트 냄새
- 과하거나 불필요한 세부 정보와 관련된 테스트 냄새
- 테스트란 코드에 바라는 동작과 가정을 프로그래머식으로 표현한 것, 읽은 프로그래머는 코드가 해야 할 일을 이해하고 실제로 한 일이 무엇인지 말할 수 있어야 한다.
기본타입 단언
- 단얼하려는 이유나 의도가 의미를 알 수 없는 단어나 숫자에 가려진 상황
- 검새해야 할 동작보다 더 기초적인 요소에 집착하는 것
- 개선방법
- API 추상화 수준을 다시 확인한다.
- !=, == 등 비교문을 사용하는 단언문의 추상화 수준을 올린다.
광역 단언
- 테스트가 실패하는 이유는 오직 하나뿐 이어야 한다. (단일 책임의 원칙)
- 본래 의도가 광활한 검증 범위에 묻혀 희석된다.
- 검사하려는 동작의 아주 작은 하나까지도 놓치지 않게 집착.
- 조그만 변화만 생겨도 테스트가 실패한다.
- 단언문 대부분이 실패의 원인과 아무런 관련도 없을 것이다.
- 테스트의 의도와 핵심을 파악하는데 방해가 된다.
- 개선방법
- 본질과 관련없는 세부냉용을 찾아 테스트에서 제거한다.
- 세부 정보를 숨기고 한가지 일에만 충실하게 한다.
- 핵심을 빠르게 파악할 수 있는 테스트를 만들어라.
비트 단언
- 의미 파악을 방해 하기 쉽다.
- 부울 연산자로 변환하여 가독성을 높힌다.
부차적 세부 정보
- 읽기 쉬운 코드는 읽는 이에게 그 의도와 목적과 의미를 빠르고 정화하게 보여준다.
- 부차적 세부정보 : 테스트 코드에 부수적인 정보 많은것
- 테스트 하려는 일이 진짜 명백한가? 당연하다는 말이 선뜻 나오지 않는다면 아직 다 끝난게 아니다.
- 서술형 메서드 이름으로 충분하지 않다.
- 개선 방법 : 테스트의 핵심은 정면 한가운데 있어야 한다.
- 핵심이 아닌 설정은 Private 이나 셋업 메서드로 추출
- 적절한 인자와 서술형 이름을 사용하라.
- 한 메서드 안에서는 모두 같은 수준으로 추상화 하라.
다중 인격
- 여러개의 테스트 목적인 한 개의 테스트 메서드를 공유한다.
- 하나의 메서드는 오직 한 가지만 똑바로 검사해야 한다.
- 큰 시나리오만 떼어내도 테스트 메서드에 서술적인 이름 짓기가 수월하다.
- 읽기 쉬운 코드는 목적을 명확히 전달한다. 실수했을 때 잘못된 곳을 더 정확하게 꼬집어준다. 담당하는 영역이 좁아졌기 때문이다.
- 혼란스러운 코드는 세부 정보와 큰 그림 모두를 감춰 버린다.
쪼개진 논리
- 작게 나누면 가독성과 유지보수성이 크게 좋아진다. 하지만 너무 나누면 변질된다.
- 무작정 나누기 보다는 같은 속성을 공유하는 의미있는 조각이 어디까지인지 신경쓰면서 나눠주어야 한다.
- 코드를 읽을 때 이리저리 오가지 않도록 조심하라.
- 흩어진 코드를 분석하느라 프로그래머의 인지 부하를 가중 시키고 의미와 의도를 파악하기 어렵게 한다.
- 테스트 논리나 데이터를 독립 파일로 두는 것은 합리적 이기도 하지만 일반적으로는 메서드에 함께 두는 방법을 찾는게 합리적이다.
- 데이터나 로직을 통합하는 기준 (데이터 파일을 별도로 두는건 비용이 크다)
- 짧다면 통합하라.
- 길다면 팩토리 메소드나 데이터 생성기를 만들어라.
- 이것 마저 쉽지 않다면 그냥 독립 파일로 남겨둬라. (최후의 보루)
매직 넘버
- 지역 변수나 서술형 이름ㅇ의 상수로 대체하여 의미 전달력을 키워줘야 한다.
- 간결함 보다는 가독성을 우선해야 할 때도 있다.
셋업 설교
- 테스트 메서드는 본질만을 담아 간결하게 유지하고 나머지 세부내용은 도우미 메서드로 추출하는 하면 상당한 량의 코드를 세업 메서드로 옮기기도 한다. 지저분한 셋업 메서드를 심각하게 받아들이지 않곤 한다.
- 픽스처 - 테스트가 실행하는
어떤 것이다. 시스템 속성, 정의된 상수, 셋업 메서드가 초기화환 Private 멤버 등 - 부차적인 상세정보 냄새 일종이다. 개선 방법은 아래와 같다.
- 셋업에서 핵심을 제외한 정보는 Private method 로 추출
- 알맞은 서술적 이름을 사용
- 셋업 내의 추상화 수준을 통일
- 정리해보면 줄 수는 오히려 늘기도 하지만 더 명확해 지니 손해는 아니다.
과잉보호 테스트
- NPE 를 지겹도록 마주하다보니, 많은 프로그래머는 메서드 시작 부분에 널 검사 등의 방버 코드를 넣어 자신을 보호하는 습관을 길렀다.
- 과잉보호 테스트는 테스트의 성패를 결정짓는 진짜배기 단언문에 도달하기 전까지 불필요한 중간 단계 단언문이 많이 등장하는 것을 말한다.
- 명확할수록 더 조힉ㄴ 하지만, 시시콜콜한 정보까지 모두 명확하게 해놓으면 후임 프로그래머 입장에서는 더 혼란스러울 뿐이다.
요약
이들은 테스트 가독성을 떨어뜨리고, 테스트에서 벌어지는 일이나 핵심 의도를 파악하기 어렵게 한다.
software develop engineer