현재노트

HTML 삽입 미리보기할 수 없는 소스 흔히 말해 API 컨트롤러를 테스트하는 작업이다. 저는 여기서 RestAssured 라는 테스트 라이브러리를 사용하여 설명하도록 하겠습니다. 잠깐 RestAssured를 설명하자면, spring에서는 기본적으로 MockMvc를 지원하는데 직관적이지 않고, 결과값을 체이닝 되는 점이 많아 간단하게 테스트할 수 도구가 RestAssured 입니다. HTML 삽입 미리보기할 수 없는 소스 SpringBootTest를 한꺼번에 돌리기 위해서는 port 를 Random을 돌리는 경우가 많기 떄문에 위처럼 설정을 해줘야 합니다. HTML 삽입 미리보기할 수 없는 소스 RestAssured 객체에 body에 json 값을 넣어주고 path를 입력해주면, E2E 테스트가 가능하며..

통합 테스트는 Respository나 Service단 로직을 검증하는 테스트입니다. HTML 삽입 미리보기할 수 없는 소스 springboot 기준으로 repository를 테스트할 때 @SpringBootTest 를 사용해도 되지만, Bean이 너무 많이 불러와져서 실행속도를 저하시키는 단점이 있습니다. 그래서 @DataJpaTest 를 사용하여 필요한 Bean만 불러들려 사용합니다. 테스트할 repository를 @Autowire로 빈을 가져오고 사용을 합니다. 서비스단을 테스트하는 방법은 mockito로 가짜 객체를 생성하는 방법과 h2 DB를 사용할경우에는 이것을 그대로 사용하는 방법이 있습니다. mockito로 작업하는경우 실제 DB를 사용하는것이 아닌 Fake 객체를 이용하여 반환한 값을 검증..

HTML 삽입 미리보기할 수 없는 소스 테스트는 테스트 대상 범위나 성격에 때라 E2E 테스트, Integration Test(통합 테스트), Unit Test(단위 테스트) 등 3가지로 구분합니다. 현재 여기 페이지에서는 단위 테스트에 대해서 설명을 할것입니다. 단위테스트는 클래스 범주 내에서 작은 단위(함수 단위)의 기능에 대한 유효성을 검증하는 테스트입니다. 매우 간단하고 명확하며 빠르게 실행된다는 특징이 있습니다. 본 문서는 asserts-core, junit-jupiter를 사용하여 테스트 코드를 작성하였습니다. dependencies { testImplementation 'org.assertj:assertj-core:3.22.0' testImplementation 'org.junit.jupit..

HTML 삽입 미리보기할 수 없는 소스 엔티티와 벨류 제대로 구분해야 도메인을 올바르게 설계하고 구현할 수 있기 때문에 이 둘의 차이를 명확하게 이해하는 것은 도메인을 구현하는 데 있어서 중요하다. 엔티티. 엔티티의 가장 큰 특징은 식별자를 가진다. 식별자는 엔티티 객체마다 고유해서 각 엔티티는 서로 다른 식별자를 갖는다. 엔티티의 식별자는 바뀌지 않고 고유하기 때문에 두 엔티티 객체의 식별자가 같으면 두 엔티티는 같다고 판단할 수 있다. 엔티티의 식별자 생성 특정 규칙에 따라 생성 UUID나 Nano ID와 같은 고유 식별자 생성기 사용 값을 직접 입력 일련번호 사용(시퀀스나 DB의 자동 증가 컬럼 사용) 벨류 데이터 변경 기능을 제공하지 않는 타입 → 불변 참고자료 참고자료 도메인 모델에 set 메서..

프로젝트에서 개발을 진행할 때 기획서, 유스케이스, 사용자 스토리와 같은 요구사항과 관련자와의 대화를 통해 도메인을 이해하고 이를 바탕으로 도메인 모델 초안을 만들어야 한다. 화이트보드, 종이와 연필, 모델링 툴 중 무엇을 선택하든 구현을 시작하려면 도메인에 대한 초기 모델이 필요하다. 도메인을 모델링할 때 기본이 되는 작업은 모델을 구성하는 핵심 구성요소, 규칙, 기능을 찾는 것이다. 이 과정은 요구사항에서 출발한다. 이러한 과정을 문서화를 하는 주된 이유는 지식을 공유하기 위함이다. 실제 구현은 코드에 있으므로 코드를 보면 다 알 수 있지만 코드는 상세한 모든 내용을 다루고 있기 때문에 코드를 이용해서 전체 소프트웨어를 분석하려면 많은 시간을 투자해야 한다. 전반적인 기능 목록이나 모듈 구조, 빌드 ..

일반적인 애플리케이션의 아키텍처는 아래 그림과 같이 네 개의 영역으로 구성 된다. 영역 설명 사용자 인터페이스(UI) 또는 표현 사용자의 요청을 처리하고 사용자에게 정보를 보여준다. 여기서 사용자는 소프트웨어를 사용하는 사람뿐만 아니라 외부 시스템일 수도 있다 응용 사용자가 요청한 기능을 실행한다. 업무 로직을 직접 구현하지 않으며 도메인 계층을 조합해서 기능을 실행한다. 도메인 시스템이 제공할 도메인 규칙을 구현한다. 인프라스트럭처 데이터베이스나 메시징 시스템과 같은 외부 시스템과의 연동을 처리한다. 도메인 계층은 도메인의 핵심 규칙을 구현한다. 예를 들어, 주문 도메인의 경우 ‘출고 전에 배송지를 변경할 수 있다’라는 규칙과 ‘주문 취소는 배송 전에만 할 수 있다’라는 규칙을 구현한 코드가 도메인 계..

도메인 모델? 특정 도메인을 개념적으로 표현한 것. 예를 들어 주문 도메인을 생각해 보면, 온라인 쇼핑몰에서 주문을 하려면 상품을 몇개 살지 선택하고 배송지를 입력한다. 선택한 상품 가격을 이용해서 총 지불 금액을 계산하고, 금액 지불을 위한 결제 수단을 선택한다. 주문한 뒤에도 배송 전이면 배송지 주소를 변경하거나 주문을 취소할 수 있다. 이런 요구사항들을 취합해 주문 도메인의 도메인 모델을 객체 모델로 구성하면 아래와 같다. 이와 같이, 도메인 모델을 사용하면 여러 관계자들이 동일한 모습으로 도메인을 이해하고 도메인 지식을 공유하는 데 도움이 된다. 도메인을 이해하려면 도메인이 제공하는 기능과 도메인의 주요 데이터 구성을 파악해야 하는데, 이런 면에서 기능과 데이터를 함께 보여주는 객체 모델은 도메인..

온라인 홍보, 정산, 배송 등 각 영역에는 전문가가 있다. 이들 전문가는 해당 도메인에 대한 지식과 경험을 바탕으로 본인들이 원하는 기능 개발을 요구한다. 개발자는 이런 요구사항을 분석하고 설계하여 코드를 작성하며 테스트하고 배포한다. 요구사항을 올바르게 이해하지 못하면 요구하지 않은 엉뚱한 기능을 만들게 된다. 따라서, 코딩에 앞서 요구사항을 올바르게 이해하는 것이 중요하다. 요구사항을 올바르게 이해하려면, 개발자와 전문가가 직접 많은 대화를 나누어야 한다. 제품 개발과 관련된 도메인 전문가, 관계자, 개발자가 같은 지식을 공유하고 직접 소통할수록 도메인 전문가가 원하는 제품을 만들 가능성이 높아진다. 개발자는 요구사항을 이해할 때 왜 이런 기능을 요구하는지 또는 실제로 원하는 게 무엇인지 생각하고 전..