feel_2

Backing Service란? backing services는 앱이 실행중에 네트워크를 통해 사용하는 모든 서비스를 말합니다. 예로는 데이터 저장소(예: MySQL 또는 CouchDB), 메시징/대기열 시스템(예: RabbitMQ 또는 Beanstalkd), 아웃바운드 이메일용 SMTP 서비스(예: Postfix) 및 캐싱 시스템(예: Memcached, Redis)이 있습니다. 여기서 key point 는 앱이 실행중에 네트워크를 통해 사용하는 모든 서비스 로 볼 수 있다. 쉽게 backup(지원요청)을 위한 컴퍼넌트라고 생각하면 된다. Microservices for Backing Service 이벤트드리븐 기반의 마이크로서비스(Event-Driven Microservices)에서 Backing S..

Service Mesh란? 서비스 메시는 애플리케이션의 서비스 간 모든 통신을 처리하는 소프트웨어 계층입니다. 이 계층은 컨테이너화된 마이크로서비스로 구성됩니다. … 서비스 메시는 서비스 간 연결을 관리하기 위해 모니터링, 로깅, 추적, 트래픽 제어와 같은 새로운 기능을 제공합니다. 이러한 기능은 각 서비스의 코드와 독립적이므로 네트워크 경계를 넘어 여러 서비스 관리 시스템에서 작동할 수 있습니다. - aws 여기서 key point 는 서비스 레벨에서의 모든 통신을 처리 모니터링, 로깅, 트래픽 제어 서비스의 코드와 독립적(종속성 완화) 로 볼 수 있다. Why Use Service Mesh? 마이크로서비스 아키텍처를 사용하면 개발자는 전체 재배포 없이도 각 앱 서비스를 변경할 수 있습니다. 다른 아키..

API Gateway란? API Gateway(게이트웨이)는 API 서버 앞단에서 모든 API 서버들의 엔드포인트를 단일화하여 묶어주고, API에 대한 인증과 인가 기능에서 메시지에 따라서 여러 서버로 라우팅하는 고급기능까지 많은 기능을 담당할 수 있습니다. - MSA school 여기서 key point 는 엔드포인트를 단일화 인증과 인가 기능 라우팅 로 볼 수 있다. 다양한 사용자(Mobile, Brower, Other Service..)들이 External Gateway를 통해서 service에 접근하는 것을 볼 수 있다. 보통 MSA에서 API Gateway를 얘기하면 External Gateway를 말한다. Why Use an API Gateway? 다음과 같은 이유로 API Gateway를 사..

일반적으로 작은 범위의 단위 테스트만으로는 서비스 전체의 신뢰성, 무결성을 보장할 수 없다. 기능 전체의 정상 작동을 보장하기위해 여러 모듈이 협력하여 제공하는 기능을 통합적으로 테스트해보자. 7.1. E2E 테스트의 범위 End to End 테스트는 서비스의 흐름을 처음부터 끝까지 테스트하는 것을 의미한다. 사용자의 요청에서부터 데이터베이스까지 (혹은 (가능하다면) 외부 연계시스템까지) 모든 구성 요소를 포함하여 테스트를 진행한다. 테스트의 비용이 상대적으로 크더라도 애플리케이션의 무결성을 보장하기 위해 E2E 테스트를 수행하자. (시작점을 브라우저로 둘 수도 있다. 하지만 여기에서는 브라우저에서의 기능 테스트는 제외한 사용자 요청 자체를 시작점으로 잡았다. 브라우저의 기능 테스트도 가능하다고 한다. ..

사용자의 요청을 먼저 받고 Controller 가 있는 프레젠테이션 계층의 단위 테스트에 대해 알아보자. 그리고 mocking 처리 개념과 validation 에 대한 처리에 대해서도 알아본다. 6.1. Presentation Layer 특징 프레젠테이션 계층은 클라이언트로 부터 요청을 잘 받는지, 받아야 할 데이터는 모두 정확히 들어왔는지 확인이 필요하다. 이러한 프레젠테이션 계층 테스트는 단위 테스트 성격을 띤다. 프레젠테이션 계층에도 서비스 계층의 요소 등이 있을 것이다. 그럼 다른 계층에 의존성을 가지는데 어떻게 단위 테스트 처럼 테스트를 진행할 수 있을까? 바로 의존성을 가지는 다른 계층의 부분을 @MockBean 를 활용해 가짜로 타계층의 요소를 만들어 테스트를 진행하는 방식이다. 6.2. M..

Business Layer, 비즈니스 계층은 서비스의 핵심 로직이 집중 되어 있는 계층이다. 서비스 로직은 보통 데이터를 다루므로 Business Layer은 단독 계층 테스트가 아닌, Persistence Layer 와 함께 통합적으로 테스트를 진행한다. 서비스 테스트를 진행하며, 테스트에 용이하게 로직을 개선하면서 전체적인 로직도 개선되는 선순환을 만들 수 있도록 해보자. ( 관심 있다면 TDD 개념도 살펴보면 좋을 것 같다.) 5.1. 기본적인 Business Layer Test 비즈니스 계층 테스트에서 테스트관련 새로운 내용은 상대적으로 없으나, 샘플로 작성한 서비스 로직, 엔티티 관계에 대해 먼저 살펴보고 서비스 테스트 내용을 보는 걸 추천한다. 5.1.1. Entity 준비 비즈니스 로직을 작..

지금부터는 외부 시스템과의 연계에서 어떻게 테스트를 진행해야 하는지에 대해서 알아보자. 4.1. Mock에 대한 고찰 https://feel2.tistory.com/35 여길 통해 먼저 테스트 대역으로의 Mock과 도구로서의 Mock의 차이, 테스트 대역에서의 Mock 과 Stub 의 차이를 알아보고 오자. https://feel2.tistory.com/32 또한 테스트를 바라보는 관점을 이를 통해 미리 알아보고 오자. 앞에 두 글을 읽고 왔다고 가정하고 이 글을 계속해서 진행해 보겠다. 지금부터 필자가 말하는 Mock은 도구로서의 Mock이라는 것을 상기하자. 테스트를 바라보는 관점은 크게 Mock을 쓰지 않는 관점과 Mock을 쓰는 관점이 있다. 필자가 생각했을 때 제일 좋은 것은 두 가지 모두 적절..

이전 페이지에서 계층형 아키텍처에 대해 살펴보았다. 앞으로는 3계층 아키텍처의 계층들을 어떻게 테스트 하는지 알아보자. 첫 번째로 퍼시스턴스 레이어를 대상으로 한 Repository 테스트 방법에 대해 살펴본다. 그리고 퍼시스턴스 계층이 데이터 접근이라는 관심사에 대해 분리가 되어 있는지, 다른 계층에 대해 결합도가 낮은지, 테스트가 용이한지 같이 살펴보자. (참고: Builder Pattern, Intellij 의 live template 설정 방법) 3.1. 기본적인 Repository Test 상품 도메인, 상품 판매 상태 Enum, 그리고 상품을 조회하는 repository를 작성하였고, 그에 대한 테스트 코드이다. 3.1.1. 원하는 판매상태를 가진 상품들을 조회한다 3.1.2. 상품번호 리스트..

애플리케이션의 아키텍처 소개와 웹 서비스에서 많이 사용하는 3계층 아키텍처에 대해 소개한다. 계층형 아키텍처를 통해 종속적이지 않는, 유연한 구조로, 테스트에 용이한 개발을 하는데 배경지식을 쌓아보자. (참고: 각 그림에는 출처로 링크 걸어두었다.) 2.1. 애플리케이션의 아키텍처 애플리케이션의 아키텍처를 설명할 때 많이 언급되는 계층형 아키텍처와 육각형 아키텍처를 소개한다. https://jojoldu.tistory.com/603 Layered Architecture: 애플리케이션의 아키텍처를 ‘계층’으로 나누어 바라봄 Hexagonal Architecture: 도메인은 영속성에 독립적으로 존재하기 위해 (육각형의) 제일 안 쪽에 개념이 존재하고, DB, HTTP, API 등 다른 채널들과 통신할 때는..

기본적인 단위 테스트에 대해 알아본다. 1.1. 단위 테스트 작은 코드 단위(클래스 or 메서드)를 독립적으로 검증하는 테스트이다. 검증 속도가 빠르고, 안정적인 장점이 있다. 1.2. 준비 및 환경설정 Project 설정 jdk 11 spring-boot 2.7.17 dependency: spring-boot-starter-data-jpa, spring-boot-starter-web, spring-boot-starter-test, com.h2database(버전주의), lombok -group: msa -artifact: tc JUnit5(단위 테스트를 위한 테스트 프레임워크) AssertJ(테스트 코드 작성을 원활하게 돕는 테스트 라이브러리) H2 Database: 로컬에 h2 데이터베이스를 다운 받..