IT LAB

블라디미르 코리코프 님의 "단위 테스트" 책을 정리한 포스팅입니다. 2. 가치 있는 단위 테스트를 위한 리팩터링하기고객 관리 시스템이메일 변경사용자 이메일이 회사 도메인에 속한 경우, 해당 사용자는 직원으로 표시됨 (그렇지 않으면 고객으로 간주)시스템은 회사의 직원 수를 추적해야 함이메일이 변경되면 시스템은 메시지 버스로 메시지를 보내 외부 시스템에 알려야 함 초기 구현항목설명도메인 유의성사용자 식별- UserType을 통해 사용자가 직원인지 고객인지 구별 (이메일 도메인에 따라 결정)복잡도직원 수 업데이트- 이메일 도메인에 따라 사용자 유형을 변경하고, 직원 수를 업데이트하는 로직 포함협력자명시적: userId, newEmail (값 전달 방식으로 협력, 협력자 수에 포함되지 않음)암시적: Databa..

블라디미르 코리코프 님의 "단위 테스트" 책을 정리한 포스팅입니다.1. 리팩터링할 코드 식별하기코드 유형항목설명복잡도코드 내 의사 결정 지점 수로 정의도메인 유의성코드가 프로젝트의 도메인에 대해 얼마나 의미 있는가협력자 수코드가 의존하는 객체의 수- 가변 의존성외부 의존성이 얼마나 자주 바뀌는지- 외부 의존성외부 시스템에 대한 의존성 험블 객체 패턴을 사용해 지나치게 복잡한 코드 분할하기지나치게 복잡한 코드복잡도 및 도메인 유의성도 높고 협력자 수도 많은 코드테스트가 어렵고, 변경하기도 어려우며, 버그가 생기기 쉬움 예시) 프레임워크 의존성 (비동기)더보기@Servicepublic class NotificationService { @Async public void sendEmail(String..

블라디미르 코리코프 님의 "단위 테스트" 책을 정리한 포스팅입니다.1. 함수형 아키텍처 이해함수형 프로그래밍구분설명예시 / 비고정의수학적 함수를 사용한 프로그래밍 방식숨은 입출력이 없음핵심 특성- 메서드 시그니처에 모든 입출력이 명시됨- 동일 입력 → 동일 출력 (호출 횟수 상관 ❌)- 상태 변화 ❌순수 함수참조 투명성어떤 표현식이 항상 같은 값으로 대체될 수 있는 성질테스트 용이 (리팩토링 내성 강함) 예시) 순수 함수더보기// 순수 함수 - 함수형 프로그래밍의 핵심public int add(int a, int b) { return a + b;} 숨은 입출력 메서드의 시그니처에는 명시되지 않지만, 외부 상태에 영향을 주거나 영향을 받는 동작들.유형예시설명 및 문제점부작용 (출력)file.write..

블라디미르 코리코프 님의 "단위 테스트" 책을 정리한 포스팅입니다.1. 단위 테스트의 세 가지 스타일설명출력 기반 테스트상태 기반 테스트통신 기반 테스트검증 항목함수의 반환 값만 검증시스템의 상태나 의존성의 상태 변경 검증협력자와의 상호작용, 통신 여부 검증예시함수형 프로그래밍- 순수 함수 (로직, 부작용 ❌)도메인 모델 상태 변화- 결제 후 주문 상태가 "완료"로 변경되었는지 검증외부 시스템 호출- 주문 서비스가 결제 서비스에 호출을 했는지 검증- 호출된 파라미터가 맞는지 검증 예시) 출력 기반 테스트더보기더보기public class Calculator { public int add(int a, int b) { return a + b; }}public class Calculato..

블라디미르 코리코프 님의 "단위 테스트" 책을 정리한 포스팅입니다.3. 목과 테스트 취약성 간의 관계육각형 아키텍처도메인을 중심으로, 포트(Port)와 어댑터(Adapter)를 통해 외부와의 상호작용을 처리하는 구조구성 요소설명Domain핵심 비즈니스 로직. 의존성 없음 (순수 계층)Port (Interface)외부와 상호작용하기 위한 입출력 인터페이스Adapter외부 시스템 구현체 (DB, Email, API 등)Application Service도메인 호출 + 외부 시스템과의 조율 담당 예제) Order더보기도메인public class Order { private String orderId; private String customerId; private List items; pr..

블라디미르 코리코프 님의 "단위 테스트" 책을 정리한 포스팅입니다. 1. Mock vs Stub테스트 대상 시스템과 그 협력자 사이의 상호 작용을 검사할 수 있는 테스트 대역구분Mock (목)Stub (스텁)역할외부와의 상호 작용을 모방하고 검증내부로 들어오는 입력/행위를 모방목적협력 객체가 정확히 호출되었는지협력 객체에서 예상 데이터 제공방향Out-boundIn-bound검증 여부✅ 상호작용 검증 (호출 횟수, 순서, 인자 등)❌ 결과 검증만적합한 상황부작용 발생 확인 (Command)데이터 주입 (Query)주의사항과도하면 구현에 종속됨상호작용 검증은 하지 말 것테스트 위험과잉 명세구현 세부사항 노출예시이메일 전송 여부, 결제 API 호출 여부 등DB에서 회원 조회 결과 반환, 외부 API에서 응답 ..

블라디미르 코리코프 님의 "단위 테스트" 책을 정리한 포스팅입니다.3. 이상적인 테스트를 찾아서테스트의 가치좋은 단위 테스트의 4대 특성을 곱하여 얻은 결과 (추정치)소수의 가치있는 테스트가 평범한 테스트보다 프로젝트 성장에 훨씬 더 효과적테스트 스위트에 테스트를 계속 둘지 여부를 결정할 수 있음임계치를 충족하는 테스트만 두어, 책임을 적절하게 맡도록 해야 함 이상적인 테스트를 만들 수 있는가?이상적인 테스트는 네 가지 특성 모두에서 최대 점수를 받는 테스트실제로는 세 가지 특성(회귀 방지, 리팩터링 내성, 빠른 피드백)이 서로 충돌함 모두를 동시에 만족하는 것은 불가능함 핵심 전략항목설명하나의 특성을 완전히 버릴 수 없다하나를 버리면 곱셈 규칙(가치의 곱)에 의해 전체 테스트의 유용성이 0에 가까워짐리..

블라디미르 코리코프 님의 "단위 테스트" 책을 정리한 포스팅입니다.1. 좋은 단위 테스트의 4대 요소요소설명문제 상황 / 원인해결 방안회귀 방지코드 수정 후 기능이 깨지는 것을 방지하는 테스트 역할코드 수정 후 테스트는 통과하지만 실제로는 동작하지 않음기존 동작을 명확히 검증리팩터링 내성코드 내부 구현이 변경되어도 테스트가 정상적으로 동작해야 함리팩토링 시 내부 동작 테스트 깨짐결과 기반 테스트구현 디테일 분리빠른 피드백테스트가 빠르게 실행되어야 실시간 피드백이 가능외부 의존성으로 느려지거나 무거워짐의존성 분리 (Fake/Stub)유지 보수성가독성, 유지 비용, 실행 비용 등을 평가 └ 이해 난이도테스트가 얼마나 직관적이고 쉽게 읽히는가복잡한 준비 코드AAA 패턴 사용설명적인 테스트 이름└ 실행 난이도..

블라디미르 코리코프 님의 "단위 테스트" 책을 정리한 포스팅입니다.1. AAA 패턴테스트 코드를 세 단계로 구분하여 작성하는 패턴스위트 내 모든 테스트가 단순하고 균일한 구조를 갖게함단계설명Arrange테스트 대상(SUT) 및 의존성 설정Act테스트 대상 메서드 실행Assert결과 확인 (반환 값, 상태 변화, 호출 여부 등) 2. 권장 사항항목권장 사항이유 및 설명구절 수 제한한 테스트에는 한 act만단일 동작 검증조건문 회피분기문 피하기 (if, switch 등)복잡도 증가 (한 테스트에 여러 경우를 넣지 말고 분리해야 함)메서드 캡슐화복잡한 검증 로직 분리 (private 메서드로)반복 제거가독성 향상목적 명확화불변 위반 방지여러 호출로 결과 만들지 말 것불변성 깨질 수 있음 (한 동작 = 한 결과..

블라디미르 코리코프 님의 "단위 테스트" 책을 정리한 포스팅입니다. 2. 런던파와 고전파격리 방식에 따라 크게 두 가지 스타일로 나뉨항목런던파 (London School)고전파 (Classical School)중심 철학상호작용 기반 (행위 검증)상태 기반 (결과 검증)테스트 단위코드 조각단일 동작TDD 방식하향식 (전체 설계/인프라 → 상위 → 하위)상향식 (하위 → 상위 → 전체 설계/인프라)의존성 처리모든 의존성을 Mock으로 대체공유 의존성만 Fake/Stub으로 격리 (나머지는 실제 객체 사용)장점빠르고 정밀함현실적인 테스트단점과잉 명세구현 의존성 높음문제 원인 추적이 어려움 예제) EmailSender더보기런던파// 인터페이스public interface EmailSender { void ..