목 vs 스텁
테스트 대역은 모든 유형의 비운영용 가짜 의존성을 설명하는 포괄적인 용어다.
테스트 대역의 유형에는 목과 스텁이 있다.
테스트 대역의 주 용도는 테스트를 편리하게 하는 것이다.
테스트 대상 시스템으로 실제 의존성 대신 전달되므로 설정이나 유지보수가 어려울 수 있다.
목은 외부로 나가는 상호 작용을 모방하고 검사하는 데 도움이 된다.
이러한 상호 작용은 SUT가 상태를 변경하기 위한 의존성을 호출하는 것에 해당한다.
스텁은 내부로 들어오는 상호작용을 모방하는 데 도움이 된다.
SUT가 입력 데이터를 얻기 위한 의존성을 호출하는 것에 해당한다.
목은 의존성 간의 상호 작용을 모방하고 검사하는 반면
스텁은 모방만 한다.
스텁과의 상호 작용을 검증하지 말라
SUT에서 스텁으로의 호출은 SUT가 생성하는 최종 결과가 아니다.
이러한 호출은 최종 결과를 산출하기 위한 수단일 뿐이다.
즉 스텁은 SUT가 출력을 생성하도록 입력을 제공한다.
스텁과 상호 작용을 검증하는 것은 취약한 테스트를 야기하는 일반적인 안티 패턴이다.
테스트에서 거짓 양성을 피하고 리팩터링 내성을 향상시키는 방법은 구현 세부 사항이 아니라 최종 결과를 검증하는 것뿐이다.
최종 결과가 아닌 사항을 검증하는 이러한 관행을 과잉 명세라고 부른다.
과잉 명세는 상호 작용을 검사할 때 가장 흔하게 발생한다.
목과 스텁의 개념은 CQRS 원칙과 관련이 있다.
명령을 대체하는 테스트 대역은 목이다.
조회를 대체하는 테스트 대역은 스텁이다.
식별할 수 있는 동작과 구현 세부 사항
목과 테스트 취약성 간의 연관성을 찾기 위한 다음 단계로 이러한 취약성을 일으키는 원인을 알아보자
테스트 취약성은 리팩터링 내성에 해당한다.
테스트에 거짓 양성이 있는 주요 이유는 코드의 구현 세부 사항과 결합돼 있기 때문라는 것을 알았다.
강결합을 피하는 방법은 코드가 생성하는 최종 결과를 검증하고 구현 세부 사항과 테스트를 가능한 한 떨어뜨리는 것 뿐이다.
어떻게가 아니라 무엇에 중점을 둬야 한다.
모든 제품 코드는 2차원으로 분류할 수 있다.
-
공개 API 또는 비공개 API
-
식별할 수 있는 동작 또는 구현 세부 사항
-
클라이언트가 목표를 달성하는데 도움이 되는 연산을 노출하라. 연산은 계산을 수행하거나 부작용을 초래하거나 둘 다 하는 메서드다.
-
목표를 달성하는 데 도움이 되는 상태를 노출하라. 상태는 시스템의 현재 상태다.
캡슐화는 불변성 위반이라고도 하는 모순을 방지하는 조치이다.
불변성은 항상 참이어야 하는 조건이다.
구현 세부 사항을 노출하면 불변성 위반을 가져온다.
장기적으로 코드베이스 츄지 보수에서는 캡슐화가 중요하다.
복잡도 때문이다.
코드 복잡도는 소프트웨어 개발에서 가장 큰 어려움 중 하나다.
코드베이스가 점점 복잡해질수록 작업하기가 더 어려워지고 개발 속도가 느려지고 버그 수가 증가하게 된다.
계속해서 증가하는 코드 복잡도에 대처할 수 있는 방법은 실질적으로 캡슐화 말고는 없다.
캡슐화를 올바르게 유지해 코드베이스에서 잘못할 수 있는 옵션조차 제공하지 않도록 하는 것이다.
캡슐화는 궁극적으로 단위 테스트와 동일한 목표를 달성한다.
