feel_2

일반적으로 작은 범위의 단위 테스트만으로는 서비스 전체의 신뢰성, 무결성을 보장할 수 없다. 기능 전체의 정상 작동을 보장하기위해 여러 모듈이 협력하여 제공하는 기능을 통합적으로 테스트해보자. 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 데이터베이스를 다운 받..

비공개 메서드 단위 테스트 단위 테스트를 하려고 비공개 메서드를 노출하면 기본 원칙 중 하나인 식별할 수 있는 동작만 테스트하는 것을 위반한다. 비공개 메서드를 직접 테스트하는 대신, 포괄적인 식별할 수 있는 동작으로서 간접적으로 테스트하는 것이 좋다. 비공개 메서드를 절대 테스트하지 말라는 규칙에도 예외가 있다. 예외를 이해하려면 코드의 공개 여부와 목적 간의 관계를 다시 살펴봐야 한다. 식별할 수 있는 동작 구현 세부 사항 공개 좋음 나쁨 비공개 해당 없음 좋음 테스트로 유출된 도메인 지식 도메인 지식을 테스트로 유출하는 것 또한 흔한 안티 패턴임 보통 복잡한 알고리즘을 다루는 테스트에서 일어난다. 테스트를 작성할 때는 특정 구현을 암시하지 말라. 단위 테스트에서는 예상 결과를 하드코딩하는 것이 좋다..

DB 테스트를 위한 전제 조건 통합테스트에서는 관리 의존성이 그대로 있어야 한다. 형상 관리 시스템에서 DB 유지 모든 개발자를 위한 별도의 DB 인스턴스 사용 DB 배포에 마이그레이션 기반 방식 작용 참조 데이터는 애플리케이션이 제대로 작동하도록 미리 채워야 하는 데이터다. 인메모리 DB는 일반 DB와 기능적으로 일관성이 없기 때문에 사용하지 않는 것이 좋다. 또한 운영 환경과 테스트 환경이 일치하지 않는 문제가 발생한다. 일반 DB와 인메모리 DB의 차이로 인해 테스트에서 거짓 양성 또는 거짓 음성이 발생하기 쉽다. 쓰기를 철저히 테스트 하는 것이 중요하다. 위험성이 높기 때문 쓰기 작업이 잘못되면 데이터가 손상돼 DB뿐만 아니라 외부 애플리케이션에도 영향을 미칠 수 있다. 그러나 읽기는 해당하지 않..

목의 가치를 극대화하기 비관리 의존성에만 목을 사용하는 것은 목의 가치를 극대화 하는 첫번째 단계일 뿐이다. 목을 사용할 때는 꼭 **시스템 끝에서 비관리 의존성과의 상호 작용**을 검증하라!! IBus 는 시스템 끝에 있다. IMessgeBus는 컨트롤러와 메시지 버스 타입 사슬에서 중간 고리일 뿐이다. IMessageBus 대신 IBus를 목으로 처리하면 회귀 방지가 좋아진다. 목 처리에 대한 모범 사례 비관리 의존성(외부 시스템)에만 목 적용하기 시스템 끝에 있는 의존성에 대해 상호 작용 검증하기 목은 통합 테스트만을 위한 것이다. 도메인 모델(persistance Layer) 은 단위 테스트 범주에 속하고, 컨트롤러를 다루는 테스트(presentation Layer)는 통합 테스트다. 테스트당 목..