목은 상호 작용을 검사할 수 있는 테스트 대역이라고 했었다.
테스트 대역의 다른 유형이 바로 스텁(STUB)이다.
두 유형의 차이점
목은 관련 의존성으로 나가는 상호 작용을 검사하지만 스텁은 내부로 들어오는 상호 작용 모방하고 검사하지 않는다. SUT에서 스텁으로의 호출은 SUT가 생성하는 최종 결과가 아니다 이러한 호출은 최종 결과를 산출하기 위한 수단일 뿐이다. => 4장에서 최종결과만을 검사하는것!
단위 테스트에서 리팩터링 내성 지표가 있는지 여부는 대부분 이진 선택이므로 리팩터링 내성 지표가 가장 중요하다.
4장에서 테스트에 거짓 양성이 있는 주요 이유는 코드의 구현 세부 사항과 결합돼 있기 때문이다. 이를 필하기 위해서는 코드가 생성하는 최종 결과를 검증하고 구현 세부 사항과 테스트를 최대한 떨어뜨리는 것뿐이다.
모든 제품 코드는 2차원으로 분류할 수 있다.
공개 API또는 비공개 API
식별할 수 있는 동작 또는 구현 세부 사항
각 차원의 범주는 겹치지 않는다
식별 할 수 있는 동작과 구현 세부상항에는 미묘한 차이가 있다. 식벼할 수 있는 동작이라면 다음중 하나를 해야한다.
구현 세부 사항은 위의 두개중 그 어느 것도 하지 않는다.
이상적으로 시스템 공개 API는 식별할 수 있는 동작과 일치해야 하고 모든 구현 세부 사항은 클라이언트 눈에 보이지 않아야한다.
클래스가 구현 세부사항을 유출하는지 판단하는데 도움이 되는 유요한 규칙이있다. 단일한 목표를 달성하고자 클래스에서 호출해야하는 연산의 수가 1보다 크면 유출하고 있을 가능성이 있다.
s tring normalizedName = user.NormalizeName(newName); user.Name = normalizedName;
리팩터링 후-> user.Name = newName;
캡슐화는 분변성 위반이라고도 하는 모순을 방지하는 조치이다.
어플리케이션 서비스 계층은 도메인 계층위에 있으며 외부 환경과의 통신을 조정한다.
어플리케이션 서비스에 대한 조정의 예이다.
어플리 케이션 서비스 계층과 도메인 계층의 조합은 육각형을 형상하고 다른 어플리케이션과 소통할 수 있다.
육각형 아키텍처의 주 목적은 다음과 같다.
각 계층의 API를 잘 설계하면 테스트도 프랙탈 구조를 갖기 시작한다.
연산을 수행하기위한 도메인 클래스간 협력은 식별할 수 있는 동작이 아니기에 시스템 내부 통신은 구현 세부 사항에 해당한다. 이러한 협력은 클라이언트 목표와 직접적인 관계가 없기에 테스트가 취약해질 수 있다.