추가

Author: 김현수

07.단위테스트/정리.md

@@ -88,7 +88,7 @@
 
 
 
-**예시 #1 private 메서드를 테스트 하지 마라.**
+**예시 #1 private 메서드를 테스트 하지 마라.** (= 연산과 상태를 최소한 노출하자)
 
 클라이언트가 **목표**를 달성하는데 직접 도움 되는 **결과(식별할 수 있는 동작)만 public으로 공개해야하며 이를 테스트**하자.
 
@@ -100,12 +100,8 @@
 
 
 
-
-
 **예시 #2 stub으로 상호 작용을 검증하지 마라.  (주의 : mock 아님)**
 
-
-
 스텁과의 상호작용을 검증하는 것은 취약한 테스트를 야기하는 안티패턴이다**.**
 
 스텁으로의 호출은 최종 결과를 산출하기 위한 수단일 뿐이다. 
@@ -126,9 +122,30 @@ Assert.Equal(10, report.NumberOfUsers);// 스텁으로 상호작용 검증
 sut.Verify(x => x.GetNumberOfUsers(),Times.Once);}
 ```
 
+**예시 #3 시스템 내 클래스간의 통신을 검증하는데 목을 사용하면 구현 세부사항과 결합되며 리팩터링 내성이 미흡해진다.** 
+
+- 시스템 내부 통신 : 애플리케이션 내 클래스 간의 통신이다.
+  - 구현 세부사항이다.
+  - 내부 통신 (내부 클래스 간의 협력)과 결합하면 테스트가 취약해진다.
+- 시스템 간 통신 : 애플리케이션이 다른 애플리케이션과 통신하는 것을 말한다.
+  - 구현 세부사항이 아니다.
+  - 시스템과 통신은 방식은 전체적으로 해당 시스템을 식별할 수 있는 동작을 나타낸다.
 
 
 
+**예시 #4 모든 프로세스 외부 의존성을 목으로 대체 해야하는 것은 아니다** 
+
+- **모든 프로세스 외부 의존성을 목으로 해야하는 것은 아니다**.
+  - 프로세스 외부 의존성과 통신은 **외부에서 관찰할 수 없으면 구현 세부사항** 이다. 즉 프로세스 외부 의존성이 애플리케이션을 통해서만 접근 가능하다면, 이러한 의존성과 통신은 시스템에서 식별할 수 있는 동작이 아니다. 리팩터링 후에 그대로 유지할 필요가 없으므로 목으로 검증해서는 안된다.
+- **완전히 통제권을 가진 프로세스 외부 의존성에 목을 사용하면 깨지기 쉬운 테스트**로 이어진다.
+
+> - 공유 의존성이 프로세스 내부에 있으면 각 테스트 실행 시 해당 의존성을 새 인스턴스로 써서 재사용 피하기 쉬움
+> - 공유 의존성이 프로세스 외부에 있으면 각 테스트 실행전 db를 인스턴스화하거나 메시지버스를 새로 준비할 수 없다. (이렇게하면 너무 느려짐) -> 일반적인 접근은 테스트 대역, 즉 목과 스텁으로 교체한다.
+
+> - 목을 사용한 동작 검증  
+>   - 종종 목이 동작을 검증한다고 한다. 하지만 대부분 그렇지 않다.
+>   - 목표를 달성하고자 각 개별 클래스가 이웃 클래스와 소통하는 방식은 식별할 수 있는 동작과는 아무런 관계가 없다. (이는 구현 세부사항이다.)  
+>   - **목은 어플리케이션의 경계를 넘나드는 상호작용을 검증할 때와 이러한 상호작용의 사이드 이펙트가 외부 환경에서 보일 때만 동작과 관련**이 있다.
 
 ## **두번째, 험블 객체 패턴 사용 (= 테스트하기 어려운 코드와 쉬운 코드 분리)**
 
@@ -273,11 +290,15 @@ export class OrderService {
 ### **하지만 현실적으로 객체지향에서 모든걸 순수 함수로 만들 수 없다.**
 
 - 모든 코드베이스를 함수형 아키텍처로 전환할 수 없다. 시스템의 **복잡도와 중요성을 고려해서 전략적으로 적용**
+- 함수형 프로그래밍의 목표는 사이드 이펙트를 완전히 제거하는 것이 아니라 비즈니스 로직을 처리하는 코드와 사이드 이펙트를 일으키는 코드를 분리하는것이다.
 
 
 
 > - 여기서는 순수함수로만드는 함수형 아키텍처를 예시로 들었지만
+> - 육각형 아키텍처는 도메인 계층으로 인한 사이드 이펙트도 문제없다.
 > - 순수함수로 못만드는경우도 험블 객체 패턴을 이용하면 비즈니스 로직과 외부 의존성과의 통신을 분리하게 함으로써 협력자 수가 줄고 도메인 유의성이 높아져서 테스트하기가 쉬워진다. (헥사고날 아키텍처)
+>   - 하지만 상태기반 테스트는 거짓 양성이 되기 쉽다. 확률적으로 테스트와 제품 코드간의 결합도가 클수록 유출되는 구현 세부사항에 테스트가 얽매일 가능성이 높음
+>
 >
 > <img src="https://raw.githubusercontent.com/hscom96/ImageStore/main/images/2023/06/17/image-20230617214941673.png" alt="image-20230617214941673" style="width:50%;" />