developer h1 developer h1

분산 시스템, 마이크로서비스 아키텍처를 공부하며 빠질 수 없는 개념인 메시지 큐에 대해 정리하고자 한다.메시지 큐의 장점디커플링(decopuling)Synchronous 한 통신은 높은 결합도를 가진다.위 다이어그램의 시스템은 높은 결합도를 가진 시스템의 예시이다.이러한 형태는 하나의 서비스라도 실패할 경우 모든 서비스가 실패하게 된다.비동기 메시징으로 통신하면 서비스 간의 결합도를 감소시킬 수 있다.(ServiceA는 메시지 큐에 발행하는 것으로 책임을 다한다.)성능 최적화Synchronous한 서비스는 요청 - 응답에 필요하지 않은(관심사가 아닌) 작업들까지 기다려야 한다.  작업을 A ~ D 까지 수행하고, 각 작업 당 500ms가 걸린다고 가정했을 때 clientA는 2000ms의 Latency가..

WebFlux는 Spring 5 에서 도입된 비동기 웹 프레임워크로, Reactive Programming을 기반으로 한다. Reactivce Programming은 데이터를 비동기적으로 처리하고, 필요할 때 데이터를 가공하며, backpressure 등의 개념을 통해 시스템의 안정성을 높이는 프로그래밍 기법이다. 비동기 처리는 일반적으로 다음과 같은 방식으로 지원된다.Non_blolcking I/OWebFlux는 Netty나 Servlet 3.1+ container와 같은 논블로킹 서버를 지원한다.이러한 서버 환경 덕분에 스레드가 블로킹 되지 않고 효율적으로 I/O 작업을 처리할 수 있다.비동기 APIMono와 Flux는 비동기 API를 제공한다. 예를 들어, 'Mono.fromCallable()'은 ..

11.1 비공개 메서드 단위 테스트 11.1.1 비공개 메서드와 테스트 취약성 단위 테스트를 가능하게 하고자 비공개 메서드를 노출하게 되면 테스트가 구현에 결합되고, 결국 리팩터링 내성이 떨어진다.비공개 메서드를 직접 테스트하는 대신, 식별할 수 있는 동작으로서 간접적으로 테스트하라. 11.1.2 비공개 메서드와 불필요한 커버리지 비공개 메서드가 너무 복잡해서 공개 API로 테스트할 수 없다면, 추상화가 누락됐다는 뜻이다.비공개 메서드를 공개로 하지 말고 해당 추상화를 별도 클래스로 추출하라. 11.1.3 비공개 메서드 테스트가 타당한 경우 드물지만, 비공개 메서드가 클래스의 식별할 수 있는 동작에 속한 경우가 있다.보통 클래스와 ORM 또는 팩토리 간의 비공개 계약을 구현하는 것이 여기에 속한다. 11..

10.1 데이터베이스 테스트를 위한 전제 조건형상관리 시스템에 데이터베이스 유지모든 개발자를 위한 별도의 데이터베이스 인스턴스 사용데이터베이스 배포에 마이그레이션 방식 적용 10.1.1 데이터베이스를 형상 관리 시스템에 유지 데이터베이스 스키마를 소스 코드와 같이 형상 관리 시스템에 저장하라.테이블, 뷰, 인덱스, 저장 프로시저와 데이터베이스 구성 방식에 대한 청사진이 되는 기타 모든 항목 등이 데이터베이스 스키마에 해당된다. 10.1.2 참조 데이터도 데이터베이스 스키마다 참조 데이터도 데이터베이스 스키마에 해당한다.이는 애플리케이션이 제대로 작동하도록 미리 채워져야 하는 데이터다.참조 데이터와 일반 데이터를 구별하려면 애플리케이션에서 해당 데이터를 수정할 수 있는지 확인하면 된다.수정할 수 있으면 일..

9.1 목의 가치를 극대화하기 9.1.1 시스템 끝에서 상호작용을 검증하기 시스템 끝에서 비관리 의존성과의 상호 작용을 검증하라.컨트롤러와 비관리 의존성 사이의 타입 사슬에서 마지막 고리를 목으로 처리하라.이로써 회귀 방지(통합 테스트로 검증된 코드가 더 많기 때문) 와 리팩터링 내성(코드의 구현 세부 사항에서 목을 분리하기 때문)이 향상될 수 있다. 9.1.2 목을 스파이로 대체하기 스파이는 직접 작성한 목이다.시스템 끝에 있는 클래스에 대해서는 스파이가 목 보다 낫다.검증 단계에서 코드를 재사용해 테스트 크기가 줄고 가독성이 개선된다.검증문을 작성할 때 제품 코드에 의존하지 말라. 테스트에서 별도의 리터럴과 상수 집합을 사용하라. 필요하면 리터럴과 상수를 복제하라.테스트는 제품 코드와 독립적으로 검사..

이 장에서는 아래와 같은 내용을 다룬다.통합 테스트의 역할 이해테스트 피라미드의 개념 자세히 살피기가치 있는 통합 테스트 작성 8.1 통합 테스트는 무엇인가? 8.1.1 통합 테스트의 역할 통합 테스트는 단위 테스트가 아닌 테스트에 해당한다.통합 테스트는 시스템이 프로세스 외부 의존성과 통합해 작동하는 방식을 검증한다.통합 테스트는 컨트롤러를 다루고, 단위 테스트는 알고리즘과 도메인 모델을 다룬다.통합 테스트는 회귀 방지와 리팩터링 내성이 우수하고, 단위 테스트는 유지 보수성과 피드백 속도가 우수하다. 8.1.2 다시 보는 테스트 피라미드 통합 테스트의 기준은 단위 테스트보다 높다.통합 테스트에서 회귀 방지와 리팩토링 내성 지표에 대한 점수는 단위 테스트보다 유지 보수성과 피드백 속도가 떨어진 만큼은 높..

4, 5장에서는 가치 있는 테스트를 식별하기 위한 기준을 소개했다.6장에서는 코드 베이스를 함수형 아키텍처로 전환하고, 출력 기반 테스트를 적용하는 방법을 소개했다.이번 장에서는 함수형 아키텍처를 적용할 수 없는 애플리케이션을 포함해,더 넓은 범위의 애플리케이션에 대한 방식으로 일반화하여 더 가치 있는 테스트를 작성하는 방법과 관련해 실용적인 지침을 알아본다. 7.1 리팩터링할 코드 식별하기 7.1.1 코드의 네 가지 유형 코드 복잡도코드에서 의사 결정 지점 수에 따라 명시적으로 그리고 암시적으로 정의된다.도메인 유의성프로젝트의 문제 도메인에 대해 코드가 얼마나 중요한지를 보여준다.복잡한 코드는 종종 도메인 유의성이 높고 그 반대의 경우도 있지만, 모든 경우에 100%에 해당하지 않는다.복잡한 코드와 도..

6.1단위 테스트의 세 가지 스타일출력 기반 테스트SUT에 입력을 넣고 출력을 점검하는 방식이다.이러한 단위 테스트 스타일은 전역 상태나 내부 상태를 변경하지 않는 코드에만 적용되므로 반환 값만 검증하면 된다.출력 기반 단위 테스트 스타일은 함수형이라고도 한다.이 이름은 사이드 이펙트 없는 코드를 선호를 강조하는 방식인 함수형 프로그래밍에 뿌리를 두고 있다. 이 장의 후반부에서 함수형 프로그래밍과 함수형 아키텍처를 자세히 설명한다.상태 기반 테스트작업이 완료된 후 시스템 상태를 확인하는 것이다.SUT, 협력자, 데이터베이스, 파일 시스템 등 과 같은 프로세스 외부 의존성의 상태 등을 의미한다.통신 기반 테스트목을 사용해 테스트 대상 시스템과 협력자 간의 통신을 검증한다.6.2 단위 테스트 스타일 비교출력..