CodingING

멀티 모듈

codingtori — Mon, 10 Nov 2025 14:52:35 +0900

멀티모듈이란, 하나의 프로젝트를 여러 개의 독립적인 모듈로 나누어 관리하는 프로젝트 구조

공통으로 사용하는 코드를 공통으로 관리, 각 모듈을 독립적으로 배포가능, 모듈 간 서로 의존성을 가지며 연결함

모듈 : 독립적으로 운영될 수 있는 의미를 가지는 구성요소 단위

필요성

○ Web과 API에서 공통으로 사용되는 코드의 관리

○ 단일 모듈의 한계

적용

1. 프로젝트 분리의 기준 정하기

2. 각 모듈의 의존성 관리 방법 결정

3. 모듈별 독립적인 빌드와 배포환경 구성

4. 모듈간의 인터페이스 명확하게 정의, 공통 기능 별도의 모듈로 분리

5. 멀티 모듈 구조의 적용은 지속적인 리팩토링과 개선 과정을 통해 이루어짐

* 도메인 관점에서 진행할 경우

- 팀 단위 작업 분리, 유지보수 용이, 비즈니스 로직 집중, 확장성

- 중복 코드의 단점 가질 수 있음

멀티 모듈 경계 나누기

- Boot (서버 모듈)

- Infra (연동 모듈)

- Cloud (클라우드-시스템 모듈)

- Data (데이터 모듈 + 도메인)

공통 모듈의 저주

- 필요하지만 변경이 모든 모듈에 영향을 끼칠 수 있으므로 가장 엄격하게 관리되어야 함

모놀리틱 아키텍처

- 하나의 통합된 코드로 여러 비즈니스 기능을 수행 (전통적인 아키텍처)

참고 링크

[Spring Boot] 멀티 모듈 구조(Multi Module Architecture) 적용기

글을 시작하기 전에 최근 멀티 모듈 구조를 도입했다. 아니 정확히 말하면 도입하는 중이다.. 1차적으로 분리와 리팩토링은 완료했으나, 구조를 100%로 이해한 건 아니라서 조금씩 공부하면서 개

soso-hyeon.tistory.com

DDD : 도메인 주도 설계

codingtori — Wed, 5 Nov 2025 16:20:51 +0900

Domain Driven Design : DDD

소프트웨어 개발의 복잡성을 해결하기 위한 설계 방법론

1. 비즈니스 Domain 별로 나누어 설계하는 방식

2. 핵심 목표 : "Loosly coupling", "High cohesion" - 모듈 간의 의존성 최소화 및 응집성 최대화

3. Strategic Design(개념 설계) / Tactical Design(구체적 설계)

특징

- 도메인의 모델과 로직에 집중 (데이터 중심 → 도메인 중심 접근)

- Ubiquitous Language : 보편적 언어 사용

: 여기서 말하는 언어는 개발자도 알고 도메인 전문가도 아는 언어 == 비즈니스 용어를 하나로 통합한 공통의 언어

※ 고려사항

- Bounded Context (제한 영역) 범위 내에서 정의

- 용어 사전 (Glossary) 형태로 구성하는 것 권장 (: 처음부터 모든 용어를 사전처럼 정의하고 진행하는 것 불가)

- Software Entity와 Domain 간의 개념 일치

- 전략적 설계 (Strategic Design)

: 복잡한 도메인의 경계를 상황(Context)에 맞게 명확히 정의하는 과정 (개념적 설계)

- 도메인 이해 관계자끼리 지식을 공유하고 이해 후 정의

- 개념과 경계를 식별하여 바운디드 컨텍스트로 정의

- 경계의 관계를 컨텍스트 맵으로 정의

- 전술적 설계 (Tactical Design)

: 전략적 설계를 통해 식별된 내부를 상세하게 설계하는 과정 (구체적 설계)

- 전략적 설계에서 도출된 바운디드 컨텍스트와 도메인을 이용해 *애그리거트 패턴, 엔티티와 값 객체, 레포지토리 등 구성 및 구현

설계	전략적 설계	전술적 설계
범위	전반적	특정 Bounded-Context
목적	문제 도메인을 해결영역으로	풍부한 도메인 모델 적용
메타포	전쟁에서 전략	전투에서 전술
주요 패턴	Bounded-Context, Ubiquitous-Language	Aggregate, Domain-Event
수행 방식	접근법	상대적으로 방법론에 가까움

* Bounded Context (바운디드 컨텍스트) : 사용자 프로세스, 정책/규정 등을 고유한 비즈니스 목적별로 그룹화한 것

= 독립적으로 서비스될 때 문제가 없는 업무의 범위

* Context map (컨텍스트 맵) : 바운디드 컨텍스트 간의 관계를 도식화 한 것

* Aggregate (애그리거트) : 도메인 영역을 구성하는 요소 중 하나로, 관련된 도메인 객체들의 집합 - 즉 관련된 객체들을 모아 하나의 단위로 취급하는 개념 (아래에 더 자세하게 설명)

Domain(도메인)

- 지식 활동의 영역

- 사용자가 사용하는 것, 소프트웨어로 해결하고자 하는 문제 영역

- (프로그래머의 관점) 애플리케이션 내의 로직들이 관여하는 정보와 활동의 영역

- (DDD)관점 : 비즈니스 Domain

Domain Model (도메인 모델)

- 특정 도메인을 개념적으로 표현한 것

- 소프트웨어 기능과 데이터 구조를 비즈니스의 실제 운영과 일치 시키기 위해 사용

- 도메인 모델을 표현하는 다양한 방식(객체, 다이어그램, 그래프, 공식 등)

Domain Model Pattern (도메인 모델 패턴)

: 도메인 모델을 생성하는 패턴

구성요소

- Entity

- 고유의 식별자를 갖는 도메인 객체

- 자신의 상태와 라이프 사이클 가짐

- Value Object

- 고유한 식별자를 가지지 않는 불변 객체

- 식별성이 아닌 속성을 이용해 정의

- 불변성을 위해 setter 사용 지양

- Service

- 도메인 객체에 위치시키기 어려운 연산을 캡슐화하는 객체

- 일반적으로 상태를 갖지 않는 stateless

- 데이터를 직접 저장하거나 관리하지는 않고, 필요한 연산 수행 후 결과를 반환

- Module

- 유사 작업 및 개념을 그룹화하여 시스템 복잡도 감소시키는 설계 기법

→ JAVA의 경우 package를 사용하여 모듈 구현 : 응집도를 높이고 결합도를 낮추기 위함

- Aggregate

- 연관된 Entity와 Value Object(값 객체)를 하나로 묶은 군집

- 각각의 일관성을 보장하여 트랜잭션과 분산처리의 단위

- 개별 객체가 아닌 관련 객체를 하나로 묶어 객체 군집 단위로 모델을 볼 수 있게 함

+) 애그리거트 루트 Aggregate root

: 포함된 객체들의 대표, 하위 개념을 표현한 모델을 하나로 묶어야 할 핵심 도메인 기능을 보유하고 있는 모델

애그리거트 내에서 유일하게 외부와 상호작용할 수 있는 진입점(Entry Point)역할

- Factory

- Entity 객체의 생성에 관련된 복잡성을 캡슐화하는 설계 패턴

- 객체 생성의 전체 과정을 책임짐 → 객체 생성의 세부 사항을 걱정하지 않고, 일관된 방식으로 복잡한 객체 생성 가능

- Repository

- 도메인 영역과 데이터 infrastructure 계층 사이의 분리를 가능하게 하는 패턴

- 데이터 계층의 결합도를 낮추고 도메인 모델의 독립성 향상 → 시스템의 유연성, 확장성 증가

도메인 주도 설계 아키텍처

계층형 아키텍처 Layered Architecture

- User Interface (표현계층) : 사용자의 요청을 하위 레이어로 전달

- Application (응용계층) : 복잡한 비즈니스 로직 처리 (트랜잭션 처리 담당)

- Domain (도메인 계층): 도메인에 대한 정보, 객체 상태, 도메인의 비즈니스 로직 제공

- Infrastructure : 영속성을 구현하거나 외부와 통신하는 기능 제공 - 리포지토리 구현체, 파일 시스템 접근 등

- 도메인 계층에서 정의한 리포지토리 인터페이스를 구현하여 데이터베이스 접근을 처리

도메인 계층을 외부로 부터 보호하기 위해서, 도메인 계층이 인프라 계층에 의존하는 것을 막고자 의존성 역전 원칙 적용

* 의존성 역전 원칙 (Dependency Inversion Principle)

→ 고수준 모듈은 더이상 저수준 모듈에 의존하지 않고, 저수준 모듈은 구현 추상화한 인터페이스에 의존

추상화한 인터페이스는 저수준 모듈이 아닌 고수준 모듈에 위치

* 상위 계층이 하위 계층에 의존

Bounded Context

: 구분되는 경계를 갖는 컨텍스트

- 모델의 경계를 결정

- 한 개의 바운디드 컨텍스트는 논리적으로 한 개의 모델을 가짐

- 도메인 기능을 사용자에게 제공하는데 필요한 표현 영역, 응용 서비스, 도메인, 인프라스트럭처 영역, 테이블도 모두 포함

각각의 Context는 독립적으로 구현될 수 있으며, 통합이 필요하다

- 간접 통합 : 각 바운디드 컨텍스트가 독립성을 유지하면서 통합 (ex. 메세지 큐)

- 직접 통합 : 한 바운디드 컨텍스트가 다른 바운디드 컨텍스트의 내부 구현에 직접 접근하는 방식 (bad)

관계

- 상류, 하류 관계

: 한 쪽에서 데이터 제공(상류) , 다른 한 쪽에서는 데이터 호출 (하류)

하류에서 상류의 데이터를 받아서 사용할 때, *ACL을 만들어서 보호한다

- 공유 커널

: 두 바운디드 컨텍스트가 같은 모델을 공유하는 경우, 해당 서비스 모델을 공유함으로써 공통된 개발 막음

- 독립 방식

: 서로 통합하지 않고 모델을 발전시키는 방식

* anti-corruption layer (ACL - 부패 방지 계층)

- 레거시 시스템을 새로운 시스템으로 여러 단계에 걸처 이전할 때 사용할 수 있는 패턴

- 서로 다른 두 시스템이 망가지는 것을 방지하기 위해 사용하고 두 시스템 간의 원할한 서비스가 되도록 수행

[사용되는 상황]

○ 타 시스템 연계 (3rd party system)

○ 서로 다른 통신 프로토콜 사용 시

○ 서로 다른 도메인 모델 설계

○ 서로 다른 데이터 타입 사용

○ 서로 다른 플랫폼 인프라 계층의 연계

이벤트 스토밍 워크샵 - 업무 흐름을 이벤트 중심으로 매핑 (Bounded Context 식별)

컨텍스트 매핑

- 각 Context가 어떻게 협력하고, 데이터나 이벤트를 교환하며, 통합되는지를 시각적으로 표현함

컨텍스트 맵

: Bounded Context 간 관계 표시 (OHS: 오픈 호스트 서비스 / ACL: 안티 코럽션 계층)

컨텍스트 간 관계가 바뀔 경우 컨텍스트 맵도 변경됨

참고자료

Anti-Corruption Layer Pattern - Junhyunny’s Devlogs

Anti-Corruption Layer Pattern

junhyunny.github.io

테스트 하기 쉬운 코드 && 테스트 범위와 종류

codingtori — Tue, 14 Oct 2025 11:30:27 +0900

테스트가 어려운 코드

● 하드 코딩된 경로 : 해당 경로에 파일이 반드시 위치해야함

● 의존 객체를 직접 생성

● 정적 메서드 사용

● 실행 시점에 따라 달라지는 결과

○ LocalDate.now() 혹은 Random 사용하는 코드

● 역할이 섞여 있는 코드

● 메서드 중간에 소켓 통신 코드 포함

+) 소켓 통신이나 HTTP 통신의 경우 실제를 대체할 서버를 로컬에 띄워서 처리 가능 (서버 수준의 대역)

● 콘솔에서 입력을 받거나 결과를 콘솔에 출력

● 테스트 대상이 사용하는 의존 대상 클래스나 메서드가 final : 대역으로 대체하기 어려움

● 테스트 대상의 소스를 소유하고 있지 않아 수정이 어려움

테스트 가능한 설계

테스트가 어려운 주된 이유 = 의존하는 코드를 교체할 수 있는 수단이 없음

● 하드 코딩된 상수를 생성자나 파라미터로 받기

- [어려운 점] 테스트 환경에 따라 경로를 다르게 줄 수 있는 수단 X

- [해결 방법] 생성자나 세터를 이용해서 경로를 전달 받음

ex) 변수로 따로 분리하기, 메서드의 파라미터로 값을 전달받도록 하기

● 의존 대상을 주입 받기

- [해결 방법] 생성자나 세터를 통해 의존 대상을 교체 (: 실제 구현 대신에 대역을 사용할 수 있음)

* 만약 많은 레거시 코드에서 생성자 없는 버전 사용시 → 세터를 이용해서 의존대상 교체하도록 수정

: 이렇게 함으로써 의존대상을 교체할 수 있도록 수정한 것임

테스트하고 싶은 코드를 분리하기

- 기능의 일부만 테스트하고 싶다면 해당 코드를 별도의 기능으로 분리하여 테스트 진행

(+) 일부 기능 자체를 대역으로 변경하고 싶다면 '의존 대상을 주입받기' 에서 설명한 것처럼 세터를 이용해서 의존 대상을 주입

● 시간이나 임의 값 생성 기능 분리하기

- [어려운 점] 테스트 대상이 시간이나 임의 값을 사용하면 테스트 시점에 따라 테스트 결과가 달라짐

- [해결 방법] 테스트 대상이 사용하는 시간이나 임의 값을 제공하는 기능을 별도 분리

* 임의 값을 제공하는 라이브러리를 직접 사용하지 말고, 별도로 분리한 타입을 사용해서 대역으로 처리해야함

● 외부 라이브러리 대체 불가능한 경우 (정적 메서드 제공 시)

- [어려운 점] 정적 메소드들은 상태를 가지지 않거나 전역 상태를 사용하고, mocking이 어려움.

- [해결 방법] 외부 라이브러리를 직접 사용하지 말고 외부 라이브러리와 연동하기 위한 타입을 따로 만듬. 테스트 대상은 분리한 타입을 사용하도록 함 (: 외부 연동이 필요한 기능을 쉽게 대역으로 대체 가능)

테스트 종류

테스트 범위에 따른 테스트 종류

● 통합 테스트

○ 개발 완료 후에 진행하는 최종 테스트

○ 고객의 입장에서 요구한 기능을 올바르게 구현했는지 수행하는 테스트

○ 소프트웨어의 코드를 직접 테스트함

○ 대상 (web app의 경우) : 프레임워크, 라이브러리, 데이터베이스, 구현한 코드

● 인수 테스트

○ 고객의 입장에서 요구한 기능을 올바르게 구현했는지 수행하는 테스트

○ 요건을 완료했는지 정의하기 위해 작성한 테스트

● 기능 테스트

○ 사용자 입장에서 시스템이 제공하는 기능이 올바르게 동작하는지 확인

○ 시스템을 구동하고 사용하는데 필요한 모든 구성요소가 필요함

○ E2E 테스트에 속함

● E2E 테스트

○ 모든 구성요소를 하나로 엮어서 진행 (사용자가 사용하는 웹 브라우저 부터 시작해서 외부서비스, DB에 이르기까지)

● 단위 테스트

○ 개별 코드나 컴포넌트가 기대한대로 동작하는 지 확인

○ 한 클래스나 한 메서드와 같은 작은 범위 테스트

○ 의존 대상의 경우 스텁이나 모의 객체를 이용해서 대역으로 대체

테스트를 자동화한다 == 코드로 작성한 테스트를 실행한다

* 정기적인 기능테스트 = 정상적인 경우와 몇 가지 특수한 상황만 테스트 범위로 잡음

WireMock = 서버 API를 스텁으로 대체

WireMock 사용방법

● 테스트 실행 전에 WireMockServer 시작. 실제 HTTP 서버 뜸

● 테스트에서 WireMockServer의 동작 기술

● HTTP 연동을 수행하는 테스트 작성
● 테스트 실행 후에 WireMockServer를 중지

TestRestTemplate은 스프링 부트가 테스트 목적으로 제공. 내장 서버에 연결하는 RestTemplate.

테스트 코드

codingtori — Wed, 1 Oct 2025 16:25:52 +0900

테스트 코드의 구성요소

● 상황 == given

테스트 할 대상에 따라 상황을 설정하는 방법이 달라짐

● 실행 == when

● 결과 확인 == then

이 구조로 작성해야하는 것은 맞지만 이 구조에 너무 매몰되서도 안됨. 테스트 내용의 이해를 위해서 존재하는 것

우연에 의해 테스트 결과가 달라질 수 없도록 해야한다

ex) 파일이 없는 경우 테스트에서 현재 존재하지 않는 파일이름으로 리턴 → 명시적으로 파일이 없는 상황을 만들기

실제 존재하는 경우에도 삭제하는 로직 추가 → 항상 파일이 존재하지 않음 보장

외부 상태가 테스트 결과에 영향을 주지 않음 + 테스트 코드는 항상 정상적으로 동작하는 것이 중요함

외부 상태에 따라 테스트의 성공 여부가 바뀌지 않기 위한 방법

1. 테스트 실행 전에 외부를 원하는 상태로 만들기

2. 테스트 실행 후에 외부 상태를 원래대로 되돌려 놓기

하지만, 외부 상황은 테스트 코드에서 마음대로 제어할 수 없는 경우 존재

테스트 대상의 상황과 결과에 외부 요인이 관여할 경우 대역을 사용하면 테스트 작성이 용이해짐

● 대역 : 테스트 대상이 의존하는 대상의 실제 구현을 대신하는 구현 == test double

→ 이를 통해서 외부 상황이나 결과 대체 가능

외부 요인이 테스트에 주로 관여하는 경우

● 테스트 대상에서 파일 시스템 사용

● 테스트 대상에서 DB로 부터 데이터를 조회하거나 데이터 추가

● 테스트 대상에서 외부의 HTTP 서버와 통신

레포지토리의 경우 메모리를 이용해서 대역을 생성하여 테스트 작성 → 실제 DB를 사용하지 않고도 로직 검증가능

대역의 종류

대역 종류	설명
스텁 (Stub)	구현을 단순한 것으로 대체. 테스트에 맞게 단순히 원하는 동작을 수행.
가짜 (Fake)	제품에는 적합하지 않지만, 실제로 동작하는 구현 제공. DB대신에 메모리 이용해서 구현한 경우 이에 해당.
스파이 (Spy)	호출된 내역 기록. 기록한 내용은 테스트 결과 검증 시 사용. 스파이는 스텁에 해당함.
모의 (Mock)	기대한 대로 상호작용하는 지 행위 검증. 기대한 대로 미동작시 익셉션 발생. 모의 객체는 스텁 & 스파이 모두에 해당

* 스파이 대역 사용 예

메일 발송 기능 테스트 할 경우, EmailNotifier이 발송 이메일을 사용하였는지 테스트하면 됨

모의 객체를 작성하는 방법 중 하나에 Mockito 존재

대역 객체가 기대하는 대로 상호작용 했는지 확인하는 것이 모의 객체의 주요 기능

제어하기 어려운 외부상황의 경우 ≫ 의존을 도출하고 이를 대역으로 대신함

의존 도출 방법

1. 제어하기 힘든 외부 상황을 별도 타입으로 분리

2. 테스트 코드는 별도로 분리한 타입의 대역을 생성

3. 생성한 대역을 테스트 대상의 생성자 등을 이용해서 전달

4. 대역을 이용해서 상황 구성

이렇게 하면, 당장 로직을 구현하지 않않아도 테스트 코드를 통과시킬 수 있음

대역 사용의 장점

- 대기 시간을 줄여줌 → 개발 속도 향상

- 실제 구현이 없어도 다양한 상황에 대한 테스트 및 실행 결과 확인 가능

모의 객체 남용시,

- 결과 검증 코드가 길어지고 복잡해짐

- 기본적으로 메서드 호출 여부를 검증하는 수단이므로 테스트 대상과 모의 객체 간의 상호작용이 조금만 바뀌어도 테스트가 깨짐

☞ 따라서, DAO나 리포지토리와 같이 저장소에 대한 대역은 모의 객체를 사용하는 것보다 메모리를 이용한 가짜 구현을 사용하는 것이 테스트 코드 관리에 유리함

기능명세로서의 테스트코드 및 JUnit 기본

codingtori — Thu, 25 Sep 2025 11:07:31 +0900

설계 과정을 지원하는 TDD

테스트를 만들려면?

1. 테스트할 기능 실행

- 클래스, 메서드, 함수이름

- 파라미터

2. 결과를 검증

- 리턴 값

이러한 과정에서 이름을 고민하고 파라미터 타입과 리턴 타입을 고민한다. 이것이 곧 설계 과정이다.

이름은 설계에서 매우 중요하며, 이름이 기대하는 것과 다르게 동작할 경우 코드 분석 시간을 중가시키므로 잘 정하는 것이 중요하다

테스트 코드 작성 시,

파라미터와 결과 값을 정해야함 → 요구사항 문서에서 기능의 입력과 결과 도출 필요

구현 시 애매한 점의 경우 구체적으로 정리 필요

→ 구체적인 예를 통해서 모호함이 줄어들고, 구체적인 명세가 된다

주의 사항 - 필요할 것으로 예측해서 미리 코드를 만들면 안됨 (설계도 마찬가지)

요구사항 분석 과정에서 설계를 진행

JUnit 5

JUnit5의 요소

● JUnit 플랫폼

: 테스팅 프레임워크를 구동하기 위한 런처와 테스트 엔진을 위한 API 제공

○ junit-platform-launcher ▷ junit-platform-engine

● JUnit 주피터(Jupiter)

: JUnit5를 위한 테스트 API와 실행엔진 제공

○ junit-jupiter-engine ▷ junit-jupiter-api

● JUnit 빈티지(Vintage)

: JUnit 3과 4로 작성된 테스트를 JUnit5 플랫폼에서 실행하기 위한 모듈을 제공

○ junit-vintage-engine ▷ junit:junit

JUnit5 는 테스트를 위한 API로 주피터 API 제공

사용하기 위해서 주피터 관련 모듈 의존에 추가

1. junit-jupiter-api

2. junit-jupiter-params

3. junit-jupiter-engine

JUnit5를 이용해서 테스트 실행할 경우 JUnit5가 제공하는 플랫폼 런처 사용 필요

maven의 경우 → maven-surefire-plugin 2.22.0 버전부터 JUnit5 플랫폼 지원

<dependencies>
	<dependency>
    	<groupId>org.junit.jupiter</groupId>
        <artifactId>junit-jupiter</artifactId>
        <version>5.5.0</version>
        <scope>test</scope>
    </dependency>
</dependencies>

<build>
	<plugins>
    	<plugin>
        	<artifactId>maven-surefire-plugin</artifactId>
            <version>2.22.1</version>
        </plugin>
        ...
    </plugins>
</build>

JUnit의 Assertions 클래스

값을 검증하기 위한 목적의 다양한 정적 메서드 제공

주요 단언 메서드 정리

메서드	설명
assertEquals(expected, actual)	실제 값(actual)이 기대하는 값(expected)와 같은 지 검사
assertNotEquals(unexpected, actual)	실제 값(actual)이 특정 값(unexpected)과 같지 않은 지 검사
assertSame(Object expected, Object actual)	두 객체가 동일한 객체인지 검사
assertNotSame(Object unexpected, Object actual)	두 객체가 동일하지 않은 객체인지 검사
assertTrue(boolean condition)	값이 true 인지 검사
assertFalse(boolean condition)	값이 false인지 검사
assertNull(Object actual)	값이 null인지 검사
assertNotNull(Object actual)	값이 null이 아닌지 검사
fail()	테스트를 실패 처리

fail() 메서드의 경우, 테스트에 실패했음을 알리고 싶을 때 사용 - 특히 익셉션 발생 유무를 검증할 때 많이 사용

익셉션 발생 유무 검사 메서드

메서드	설명
assertThrows(Class<T> expectedType, Executable executable)	executable을 실행한 결과로 지정한 타입의 익셉션이 발생하는지 검사
assertDoesNotThrow(Executable executable)	executable을 실행한 결과로 익셉션이 발생하지 않는지 검사

예시 코드

IllegalArgumentException thrown = assertThrows(IllegalArgumentException.class,
    () -> {
    	AuthService authService = new AuthService();
        authService.authenticate(null, null);
    });
    
// 추가 검증
assertTrue(thrown.getMessage().contains("id"));

※ 참고 - Executable 인터페이스

: execute 함수를 가진 함수형 인터페이스

package org.junit.jupiter.api.function;

public interface Executable{
	void execute() throws Throwable;
}

assertAll()

일단 모든 검증을 실행하고 그중에 실패한 것이 있는지 확인

Executable 목록을 가변인자로 받아서 각 Executable을 수행하는 것

assertAll(
    () -> assertEquals(3, 5/2),
    () -> assertEquals(4, 2*2),
    () -> assertEquals(6, 11/2)
);

테스트 라이프사이클

@BeforeEach, @AfterEach

1. 테스트 메서드를 포함한 객체 생성

2. @BeforeEach 존재 시, 해당 어노테이션이 붙은 메서드 실행

3. @Test 어노테이션이 붙은 메서드 실행

4. @AfterEach 존재 시, 해당 어노테이션이 붙은 메서드 실행

※ @Test, @BeforeEach, @AfterEach 어노테이션을 붙인 메서드는 private이면 안됨

@BeforeAll, @AfterAll

한 클래스의 모든 테스트 메서드가 실행되기 전/후에 특정 작업을 수행해야 하는 경우

JUnit은 테스트 메서드의 실행 순서를 지정할 순 있지만, 각 테스트 메서드는 서로 독립적으로 동작해야하는 것임. 의존성이 생길경우 유지보수에 어려움이 생김

++)

@DisplayName : 메서드 이름 붙이기

@Disabled : 특정 테스트를 실행하지 않고 싶을 때 -- 테스트 코드가 완성되지 않았거나 잠시동안 테스트를 실행하지 말아야 할 때

import org.junit.jupiter.api.Disabled;

public class AssertionsTest {
    @Disabled
    @Test
    void failMethod() {
    	try{
        	AuthService authService = new AuthService();
            authService.authenticate(null, null);
           	fail();
        } catch (IllegalArgumentException e) {
        }
    }
}

모든 테스트를 실행하는 방법

● maven : mvn test

● gradle : gradle test

TDD로 기능 추가해보기

codingtori — Wed, 24 Sep 2025 23:48:38 +0900

원래 어느정도 기능이 구현되어 있던 간단한 게시판 프로젝트에 TDD를 이용해서 새로운 기능을 추가해보았다

* 기존의 회사 컴은 java 1.8 버전을 사용중이라 이 프로젝트의 실행을 위해서는 java-sdk를 version17로 변경해준다!

File → Settings → Build Tools → Gradle → Gradle JVM

내가 추가해볼 기능은 바로 댓글 좋아요 기능이다!

이때, commentLike 도메인 정도는 먼저 작성하려고 했었는데 찾아보니, TDD의 경우 도메인 코드보다 테스트 코드가 먼저!

즉, CommentLike 도메인 클래스를 먼저 만드는 것이 아니라, "이 클래스가 어떤 동작을 해야 하는지"를 테스트 코드로 먼저 정의하는 것이 출발점이라고 한다

테스트 작성 (Red 단계)

아직 CommentLike 클래스가 없더라도, "이런 기능이 있어야 한다"라는 테스트를 작성한다

이때, 고민이 되었던 부분이, 나는 다른 기능들을 개발할 경우에 모두 도메인 객체 생성 제약(@NoArgsConstructor(access = PROTECTED)를 설정해두었다. 따라서, JPA엔티티나 도메인 모델을 외부에서 함부로 new하지 못하게 해서 불변성과 일관성을 보장하려고 했는데, 테스트 코드에서도 객체 생성을 해야하다보니 어떻게 할 지가 고민이 되었다. 이때 선택지는 2가지라고 한다

정적 팩토리 메서드 사용

실제로 가장 많이 사용하는 방법이라고 한다

엔티티는 protected 생성자 그대로 두고, 대신 정적 팩토리 메서드를 만들어서 테스트/도메인 코드 모두 이걸 쓰게 하는 방식이다. 나의 경우 이전에 처음 시작할 때 바로 롬북을 쓰지 않고 정적 팩토리 메소드로 개발을 시작했어서 이미 다 만들어져 있었다

//정적 팩토리 메서드
public static Member create(String studentNumber, String nickname, String school, String email, String password, MemberStatus active) {
	return new Member(studentNumber, nickname, school, email, password, MemberStatus.ACTIVE);
}

Test Fixture - 테스트 전용 헬퍼 클래스

테스트 코드 패키지 안에 MemberFixture 같은 유틸을 두고 생성을 도와주는 정적 메서드로만 객체 생성

public class MemberFixture {
	public static Member createMember(String name) {
    	return Member.create(name);
    }
}

장점 : 도메인 변경 시에도 테스트 코드만 수정하면 됨

그럼 이제 첫 번째 테스트 코드를 작성해준다. 사용자가 댓글에 좋아요를 눌렀을 때, commentLike가 생성되는 로직을 검증하는 간단한 코드이다.

package efub.assignment.comment.domain;

import efub.assignment.community.board.domain.Board;
import efub.assignment.community.comment.domain.Comment;
import efub.assignment.community.comment.domain.CommentLike;
import efub.assignment.community.member.domain.Member;
import efub.assignment.community.member.domain.MemberStatus;
import efub.assignment.community.post.domain.Post;
import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.*;

import static org.junit.jupiter.api.Assertions.assertEquals;

public class CommentLikeTest {

    @Test
    public void 사용자는_댓글에_좋아요를_누를수가_있다() {
        //given
        Member member = Member.create("2222222", "tester", "ewha", "test@test.com", "000000", MemberStatus.ACTIVE);
        Board board = Board.create("컴공게시판", "공지사항", "desc", member);
        Post post = Post.create(board, member, true, "컴공댕들 안녕");
        Comment comment  = Comment.create(post, true, "테스트댓글", member);
        //when
        CommentLike commentLike = CommentLike.create(member, comment);
        //then
        assertEquals(member, commentLike.getMember());
        assertEquals(comment, commentLike.getComment());
    }
}

의도된 RED

아직 commentLike 클래스가 없기 때문에 에러가 발생한다 → 의도된 RED

따라서, 이 에러를 해결해주기 위하여 commentLike 도메인 클래스를 생성해준다

CommentLike 도메인 클래스 생성

package efub.assignment.community.comment.domain;

import efub.assignment.community.global.domain.BaseEntity;
import efub.assignment.community.member.domain.Member;
import jakarta.persistence.*;
import lombok.AllArgsConstructor;
import lombok.Getter;
import lombok.NoArgsConstructor;

@NoArgsConstructor
@AllArgsConstructor
@Getter
@Entity
public class CommentLike extends BaseEntity {
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long commentLikeId;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "member", nullable = false)
    private Member member;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "comment", nullable = false)
    private Comment comment;

    private CommentLike(Member member, Comment comment) {
        this.member = member;
        this.comment = comment;
    }

    public static CommentLike create(Member member, Comment comment) {
        return new CommentLike(null, member, comment);
    }
}

이때, board → post → comment → commentLike로 참조가 이어지기 때문에 각각 모두 임시로 생성해주어야 하위 항목을 생성할 수가 있다!

이제 실행해보면, 이렇게 테스트가 통과되는 것을 확인해볼 수가 있다

첫 번째 테스트 코드 통과~

그럼 이제 사용자가 같은 댓글에 중복 좋아요를 남길 수 없도록 하는 로직을 구현해보도록 하자

이전에 각 테스트에 앞서 필요한 객체들을 생성해주어야 헀는데, 이것의 코드 중복을 피하기 위해서 @BeforeEach를 이용해서

@BeforeEach
public void generateObjects(){
    Member member = Member.create(...);
    Board board = Board.create(...);
    Post post = Post.create(board, member, ...);
    Comment comment  = Comment.create(post, ...);
}

이렇게 작성해주었더니, "cannot resolve symbol" 에러가 발생

● 에러 원인 : member, board, post, comment가 generateObjects 메서드의 지역변수로만 존재하고, 실제 테스트 메서드에서 접근할 수가 없음

● 해결 방법 : 테스트 클래스의 필드로 선언하고, @BeforeEach에서 초기화 해야함

public class CommentLikeTest {
	
    private Member member;
    private Board board;
    private Post post;
    private Comment comment;

		... 생략

	// 필요한 객체들 생성
    @BeforeEach
    public void setUp(){
        Member member = Member.create("2222222", "tester", "ewha", "test@test.com", "000000", MemberStatus.ACTIVE);
        Board board = Board.create("컴공게시판", "공지사항", "desc", member);
        Post post = Post.create(board, member, true, "컴공댕들 안녕");
        Comment comment  = Comment.create(post, true, "테스트댓글", member);
    }
}

수정이전 코드

수정하고 나서 코드~ 깔끔해졌즁?

그럼 이제 테스트 코드를 돌려보면~

이런식으로 에러가 발생함을 알 수가 있다

이는 아직 commentLikeService가 존재하지 않기 때문 → 따라서 commentLikeService 를 작성해보자

commentLikeService 코드

이렇게 코드를 작성해주고 다시 테스트를 실행해준다

계속 NPE가 발생해서 물어봤더니 추가적인 에러를 알 수가 있었다...

    // 필요한 객체들 생성
    @BeforeEach
    public void setUp(){
        member = Member.create("2222222", "tester", "ewha", "test@test.com", "000000", MemberStatus.ACTIVE);
        board = Board.create("컴공게시판", "공지사항", "desc", member);
        post = Post.create(board, member, true, "컴공댕들 안녕");
        comment  = Comment.create(post, true, "테스트댓글", member);
    }

이렇게 해야된다. 원래대로 했으면, 다시 객체를 생성함으로써 앞에서 선언했던 걸 덮어씌우는 형식이 되므로 에러가 발생한다.

또한, 주입한 서비스가 여러 의존성을 가지고 있다면, 가지고 있는 모든 의존성을 @Mock으로 추가해줘야한다.!

수정한 테스트 코드

계속 유효성 검사에서 에러가 났는데 이것이 DB를 사용하는 로직이라서 그런 것 같다. 따라서 Service만 테스트하려면 Mocking으로 commentValidation과 findAllByComment 동작을 가짜로 만들어주어야 한다

또한, DB에서 member, comment 를 생성할 경우, PK는 자동으로 생성되도록 설정이 되어있는데 그 때문에 test 하는 도중에는 각 객체의 id값이 null이므로 에러가 발생한다. 이때, 이 값을 테스트를 위하여 직접 넣어줄 수 있는데

ReflectionTestUtils.setField(comment, "commentId", 1L);

이렇게 사용하면 된다

ReflectionTestUtils.setField

- Spring에서 제공하는 유틸로, private 또는 sertter가 없는 필드에 강제로 값을 넣을 때 사용

- 엔티티는 보통 id가 DB에서 자동 생성되는데, 단위 테스트에서는 DB연결이 없으니까 강제로 세팅

이렇게 해서 테스트를 다시 실행해보면, 엥......?!?

통과해버린 테스트...

● 문제 원인 : given(commentLikeRepository.findAllByComment(comment)).willReturn(List.of(...)) 처럼 정적(stub)반환을 설정하면, 서비스가 createCommentLike()에서 findAllByComment()를 호출해도 항상 같은(미리 만든) 리스트만 돌아옴. 따라서 mock의 상태는 변하지 않기 때문에(= 저장 효과가 반영되지 않음) 테스트 결과가 기대와 달라짐

● 해결 방법 : Mockito로 '상태변화' 흉내내기

findAllByComment()와 save()가 동작하는 작은 in-memory 리스트를 만들어서, findAllByComment()는 그 리스트를 읽게 하고, save()는 리스트에 추가하도록 함

수정된 CommentLikeTest

package efub.assignment.comment.domain;

import efub.assignment.community.board.domain.Board;
import efub.assignment.community.comment.domain.Comment;
import efub.assignment.community.comment.domain.CommentLike;
import efub.assignment.community.comment.dto.request.CommentLikeRequestDTO;
import efub.assignment.community.comment.repository.CommentLikeRepository;
import efub.assignment.community.comment.service.CommentLikeService;
import efub.assignment.community.comment.service.CommentService;
import efub.assignment.community.member.domain.Member;
import efub.assignment.community.member.domain.MemberStatus;
import efub.assignment.community.member.service.MemberService;
import efub.assignment.community.post.domain.Post;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.mockito.InjectMocks;
import org.mockito.Mock;
import org.mockito.junit.jupiter.MockitoExtension;
import org.springframework.test.util.ReflectionTestUtils;

import java.util.ArrayList;
import java.util.List;
import java.util.Optional;

import static org.junit.jupiter.api.Assertions.*;
import static org.mockito.ArgumentMatchers.any;
import static org.mockito.BDDMockito.given;
import static org.mockito.Mockito.*;

@ExtendWith(MockitoExtension.class)
public class CommentLikeTest {

    @InjectMocks
    CommentLikeService commentLikeService;

    @Mock
    CommentLikeRepository commentLikeRepository;

    @Mock
    MemberService memberService;

    @Mock
    CommentService commentService;

    private Member member;
    private Board board;
    private Post post;
    private Comment comment;

    private List<CommentLike> commentLikes; //테스트용 in-memory store


    @Test
    public void 사용자는_댓글에_좋아요를_누를수가_있다() {
        //given
//        Member member = Member.create("2222222", "tester", "ewha", "test@test.com", "000000", MemberStatus.ACTIVE);
//        Board board = Board.create("컴공게시판", "공지사항", "desc", member);
//        Post post = Post.create(board, member, true, "컴공댕들 안녕");
//        Comment comment  = Comment.create(post, true, "테스트댓글", member);

        //when
        CommentLike commentLike = CommentLike.create(member, comment);
        //then
        assertEquals(member, commentLike.getMember());
        assertEquals(comment, commentLike.getComment());
    }


    @Test
    public void 같은_사용자가_중복_좋아요_불가() {
        //Given

        //in-memory store 초기화
        commentLikes = new ArrayList<>();

        ReflectionTestUtils.setField(comment, "commentId", 1L);
        CommentLikeRequestDTO requestDTO = CommentLikeRequestDTO.builder()
                .member(member)
                .comment(comment)
                .build();

        //commentValidation이 comment 반환하도록 설정
        given(commentService.commentValidation(comment.getCommentId())).willReturn(comment);

//        given(commentLikeRepository.findAllByComment(comment))
//                .willReturn(List.of(CommentLike.create(member, comment)));

        //findAllByComment는 현재 commentLikes의 복사본(현재 상태) 반환
        given(commentLikeRepository.findAllByComment(comment))
                .willAnswer(invocation -> new ArrayList<>(commentLikes));

        //save가 호출되면 commentLikes에 추가하고 저장된 객체 리턴
        when(commentLikeRepository.save(any(CommentLike.class)))
                .thenAnswer(invocation -> {
                    CommentLike saved = invocation.getArgument(0);
                    commentLikes.add(saved);
                    return saved;
                });

        //When
        commentLikeService.createCommentLike(requestDTO);
        commentLikeService.createCommentLike(requestDTO);     //중복 좋아요 시도

        //Then
        assertEquals(1, commentLikeService.getCommentLikesCnt(comment));

        // save는 실제로 한 번만 호출되었어야 함 (중복이면 save하지 않도록 서비스가 구현 될 필요 有)
        verify(commentLikeRepository, atMost(1)).save(any(CommentLike.class));
    }


    // 필요한 객체들 생성
    @BeforeEach
    public void setUp(){
        member = Member.create("2222222", "tester", "ewha", "test@test.com", "000000", MemberStatus.ACTIVE);
        board = Board.create("컴공게시판", "공지사항", "desc", member);
        post = Post.create(board, member, true, "컴공댕들 안녕");
        comment  = Comment.create(post, true, "테스트댓글", member);
    }
}

테스트를 위한 in-memory store용 리스트를 생성해주고, save가 호출되면 이 리스트에 저장을 하고 저장된 객체를 리턴해줌. 그 후, service단에서 중복 호출을 방지할 것이므로 save함수 자체가 1번만 실행되어야하므로 이를 verify를 통해서 검증한다

됐다!!

중복방지로직이 없으므로 2번으로 나오는 값

그럼 이 테스트를 통과시키기 위해서 중복 방지 로직을 작성한다.

이때 set을 이용해서 구현하는 방식이랑, 일반적으로 조건문으로 분기하는 방법이 있는데, set을 사용하는 방식이 DB 조회를 덜 할 수 있는 것 같다. 하지만 일단은 DB로 갯수 조회하는 형식으로 구현을 했다

중복 로직을 구현한 CommentLikeService.java 코드

@Transactional
    public String createCommentLike(CommentLikeRequestDTO requestDTO) {
//        //1. 유효성 검사
//        Comment comment = commentService.commentValidation(requestDTO.getComment().getCommentId());
//        Member member = memberService.findMemberByMemberId(requestDTO.getMember().getMemberId());
//        if (comment == null || member == null) {
//            throw new IllegalArgumentException("댓글 좋아요 중 에러 발생");
//        }

        Comment comment = requestDTO.getComment();
        Member member = requestDTO.getMember();

        //중복 방지 로직
        if (getCommentLikesPresent(comment, member)) {
            return "이미 좋아요를 누른 댓글입니다";
        }

        //2. 좋아요 생성
        CommentLike commentLike = CommentLike.create(member, comment);
        commentLikeRepository.save(commentLike);

        return "좋아요가 생성되었습니다";
    }

    public boolean getCommentLikesPresent(Comment comment, Member member) {
        //1. 유효성 검사
        Comment cmt = commentService.commentValidation(comment.getCommentId());
        Member mem = memberService.findMemberByMemberId(member.getMemberId());
        if(cmt == null) {
            throw new IllegalArgumentException("유효하지 않은 댓글입니다");
        }
        //2. 해당 댓글에 좋아요 눌른 이력이 있는 지 반환
        Optional<CommentLike> isLiked = commentLikeRepository.findByCommentAndMember(comment, member);
        if(isLiked.isEmpty())  return false;
        else return true;
    }

코드를 작성하다보니, 숫자를 반환하는 것이 아니라 하나라도 있으면 true, 없으면 false 를 반환해서 존재 유무를 확인하고 false일 경우에만 save 메소드를 호출하는 형식으로 변환하였다

변환된 로직에 맞게 테스트 코드도 변경해줌

package efub.assignment.comment.domain;

import efub.assignment.community.board.domain.Board;
import efub.assignment.community.comment.domain.Comment;
import efub.assignment.community.comment.domain.CommentLike;
import efub.assignment.community.comment.dto.request.CommentLikeRequestDTO;
import efub.assignment.community.comment.repository.CommentLikeRepository;
import efub.assignment.community.comment.service.CommentLikeService;
import efub.assignment.community.comment.service.CommentService;
import efub.assignment.community.member.domain.Member;
import efub.assignment.community.member.domain.MemberStatus;
import efub.assignment.community.member.service.MemberService;
import efub.assignment.community.post.domain.Post;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.mockito.InjectMocks;
import org.mockito.Mock;
import org.mockito.junit.jupiter.MockitoExtension;
import org.springframework.test.util.ReflectionTestUtils;

import java.util.ArrayList;
import java.util.List;
import java.util.Optional;

import static org.junit.jupiter.api.Assertions.*;
import static org.mockito.ArgumentMatchers.any;
import static org.mockito.BDDMockito.given;
import static org.mockito.Mockito.*;

@ExtendWith(MockitoExtension.class)
public class CommentLikeTest {

    @InjectMocks
    CommentLikeService commentLikeService;

    @Mock
    CommentLikeRepository commentLikeRepository;

    @Mock
    MemberService memberService;

    @Mock
    CommentService commentService;

    private Member member;
    private Board board;
    private Post post;
    private Comment comment;

    private List<CommentLike> commentLikes; //테스트용 in-memory store


    @Test
    public void 사용자는_댓글에_좋아요를_누를수가_있다() {
        //given
//        Member member = Member.create("2222222", "tester", "ewha", "test@test.com", "000000", MemberStatus.ACTIVE);
//        Board board = Board.create("컴공게시판", "공지사항", "desc", member);
//        Post post = Post.create(board, member, true, "컴공댕들 안녕");
//        Comment comment  = Comment.create(post, true, "테스트댓글", member);

        //when
        CommentLike commentLike = CommentLike.create(member, comment);
        //then
        assertEquals(member, commentLike.getMember());
        assertEquals(comment, commentLike.getComment());
    }


    @Test
    public void 같은_사용자가_중복_좋아요_불가() {
        //Given

        //in-memory store 초기화
        commentLikes = new ArrayList<>();

        ReflectionTestUtils.setField(comment, "commentId", 1L);
        CommentLikeRequestDTO requestDTO = CommentLikeRequestDTO.builder()
                .member(member)
                .comment(comment)
                .build();

        //commentValidation이 comment 반환하도록 설정
        given(commentService.commentValidation(comment.getCommentId())).willReturn(comment);
        given(memberService.findMemberByMemberId(member.getMemberId())).willReturn(member);

//        given(commentLikeRepository.findAllByComment(comment))
//                .willReturn(List.of(CommentLike.create(member, comment)));

        //findAllByComment는 현재 commentLikes의 복사본(현재 상태) 반환
//        given(commentLikeRepository.findAllByComment(comment))
//                .willAnswer(invocation -> new ArrayList<>(commentLikes));

        //findByCommentAndMember -> 상태에 따라서 Optional 반환
        given(commentLikeRepository.findByCommentAndMember(comment, member))
                .willAnswer(invocation -> commentLikes.stream()
                        .filter(cL -> cL.getComment().equals(comment) && cL.getMember().equals(member))
                        .findFirst());

        //save가 호출되면 commentLikes에 추가하고 저장된 객체 리턴
        when(commentLikeRepository.save(any(CommentLike.class)))
                .thenAnswer(invocation -> {
                    CommentLike saved = invocation.getArgument(0);
                    commentLikes.add(saved);
                    return saved;
                });

        //When
        String msg1 = commentLikeService.createCommentLike(requestDTO);
        String msg2 = commentLikeService.createCommentLike(requestDTO);     //중복 좋아요 시도

        //Then
        assertEquals("좋아요가 생성되었습니다", msg1);
        assertEquals("이미 좋아요를 누른 댓글입니다", msg2);
        assertEquals(1, commentLikes.size());

//        // save는 실제로 한 번만 호출되었어야 함 (중복이면 save하지 않도록 서비스가 구현 될 필요 有)
//        verify(commentLikeRepository, atMost(1)).save(any(CommentLike.class));
    }


    // 필요한 객체들 생성
    @BeforeEach
    public void setUp(){
        member = Member.create("2222222", "tester", "ewha", "test@test.com", "000000", MemberStatus.ACTIVE);
        board = Board.create("컴공게시판", "공지사항", "desc", member);
        post = Post.create(board, member, true, "컴공댕들 안녕");
        comment  = Comment.create(post, true, "테스트댓글", member);
    }
}

통과한 것을 확인할 수가 있다

통과!~

사용된 개념 정리

JUnit 5 관련

@ExtendWith(MockitoExtension.class)

▷ JUnit5 테스트 확장 기능(Extension)을 추가하는 어노테이션

▷ MockitoExtension을 등록하면, 테스트 실행 시 @Mock, @InjectMocks 등을 자동 초기화

Mockito 관련

@Mock

▷ Mock 객체(가짜 객체)를 생성해주는 어노테이션

▷ 여기서는 CommentLikeRepository, CommentService를 Mock으로 만들어서 진짜 DB 접근을 막고, 원하는 반환값을 직접 설정함

@InjectMocks

▷ Mock이 아닌 실제 객체를 생성하면서, 필요한 의존성(@Mock으로 만든 객체들)을 주입해줌

▷ 여기서는 commentLikeService가 실제로 만들어지고, 그 안의 commentLikeRepository, commentService가 Mock으로 채워짐

given(...)willReturn(...)

▷ Mockito BDD 스타일 문법

▷ 특정 메서드 호출이 있을 때 정해진 값을 반환하도록 설정

given(commentService.commentValidation(comment.getCommentId()))
    .willReturn(comment);

given(...)willAnser(...)

▷ willReturn은 정해진 값만 주지만, willAnswer는 호출될 때마다 동적으로 로직을 실행시킴

▷ 여기서는 in-memory likeStore를 매번 반환하도록 했음

given(commentLikeRepository.findAllByComment(comment))
    .willAnswer(invocation -> new ArrayList<>(likeStore));

when(...)thenAnswer(...)

▷ given과 같은 기능인데, BDD 스타일이 아닌 전통적인 Mockito 문법

▷ 여기서는 save() 흉내내기 위해 사용

when(commentLikeRepository.save(any(CommentLike.class)))
    .thenAnswer(invocation -> {
        CommentLike saved = invocation.getArgument(0);
        likeStore.add(saved);
        return saved;
    });

→ save가 호출되면 전달된 객체를 likeStore에 추가하고 그대로 반환

verify(mock, times(n))

▷ Mock 객체의 메서드가 몇 번 호출됐는지 검증

▷ 예시 - save()가 최대 1번 호출되었는지 체크

verify(commentLikeRepository, atMost(1)).save(any(CommentLike.class));

코드 리뷰 반영

1. 문자열을 그대로 비교하는 것은 권장 X → .contains("좋아요")와 같이 부분 검증으로 변환

//수정 전        
        assertEquals("좋아요가 생성되었습니다", msg1);
        assertEquals("이미 좋아요를 누른 댓글입니다", msg2);

//코드리뷰 반영
        assertTrue(msg1.contains("생성되었습니다"));
        assertTrue(msg2.contains("이미 좋아요"));

mongodb/redis connect with springBoot

codingtori — Tue, 23 Sep 2025 08:01:37 +0900

의존성 추가해주기 - build.gradle

	// redis
    implementation 'org.springframework.boot:spring-boot-starter-data-redis'


	// Mongo DB
    implementation 'org.springframework.boot:spring-boot-starter-data-mongodb'

redis application.yml - local 연결용

  data:
    redis:
      host: localhost
      port: 6379

mongodb 연결 시에 host/port 가 아니라 uri 로 한 줄만 쓰는 것이 표준이라고 한다!

data:
	mongodb:
    	uri: <mongodb-connection-string>

또한, mongodb 서비스를 시작하는 명령어는 mac의 경우

brew services start mongodb/brew/mongodb-community

redisConfig도 작성해준다

package com.practice.blog.global.redis;

import org.springframework.cache.annotation.EnableCaching;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.data.redis.connection.RedisConnectionFactory;
import org.springframework.data.redis.connection.lettuce.LettuceConnectionFactory;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.data.redis.serializer.GenericJackson2JsonRedisSerializer;
import org.springframework.data.redis.serializer.StringRedisSerializer;

@Configuration
@EnableCaching // 캐싱 기능 활성화
public class RedisConfig {

    @Value("${spring.data.redis.host}")
    private String host;

    @Value("${spring.data.redis.port}")
    private int port;

    @Bean
    public RedisConnectionFactory redisConnectionFactory () {
        return new LettuceConnectionFactory(host, port);    //Redis와 통신하기 위한 클라이언트 라이브러리
    }

    //redis template을 사용하여 redis에 직접 데이터를 저장하고 조회
    @Bean
    public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory redisConnectionFactory) {
        RedisTemplate<String, Object> template = new RedisTemplate<>();
        template.setConnectionFactory(redisConnectionFactory);
        template.setKeySerializer(new StringRedisSerializer());
        template.setValueSerializer(new GenericJackson2JsonRedisSerializer());
        return template;
    }
}

이렇게 다 작성했으면 이제 실습코드 실행을 위한 account관련 코드들도 추가해주면 된다!

mongodb의 경우 repository에서 mongodb에서 제공하는 repository를 사용하면 된다

import org.springframework.data.mongodb.repository.MongoRepository;

// AccountDocument의 Repository
public interface AccountDocumentRepository extends MongoRepository<AccountDocument, String> {
}

하나의 key에 2개 이상의 필드를 가진 객체를 저장하기 위해 Hash 구조 사용

● HSET : Hash의 특정 필드에 특정 값 할당. 이미 값이 존재할 경우 덮어씀

● HGET : 특정 필드의 값 반환

● HGETALL: 특정 키에 대해 저장된 모든 필드-값 페어 조회 가능

● HMGET : 특정 필드들의 값들 반환

● HINCRBY : 특정 필드의 숫자 값을 증가 혹은 감소시킴

실습 결과 - redis

redis create/read

redis update/delete

redis-cli 캡쳐를 깜빡했다 ㅎㅎ;;

실습결과 - mongodb

mongodb create

mongodb - read

mongodb - update

mongodb - delete

테스트 코드 작성 순서

codingtori — Fri, 12 Sep 2025 12:52:59 +0900

● 쉬운 경우에서 어려운 경우로 진행

● 예외적인 경우에서 정상인 경우로 진행

방식

1. 정해진 값을 리턴

2. 값 비교를 이용해서 정해진 값을 리턴

3. 다양한 테스트를 추가하면서 구현을 일반화

이후에는 코드 중복, 메서드 추출 등의 방법을 통해서 지속적인 리팩토링 작업 필요

java.time.LocalDate 클래스의 plusMonths() 함수

: 특정 LocalDate 객체에 지정된 개월 수를 더한 새로운 LocalDate 객체를 반환하는 메서드

이 함수는 원래의 날짜를 변경하지 않고 새로운 날짜 객체를 생성하며, LocalDateTime에서도 동일한 방식으로 사용가능

* 이전 달과 이번 달의 말일이 같지 않아도 알아서 처리해줌

파라미터 개수는 적을 수록 코드 가독성과 유지보수에 유리함

→ 파라미터의 개수가 3개 이상이 될 때 객체로 바꿔 1개로 줄이는 것을 고려해야함

TDD를 시작할 때 테스트할 목록을 미리 정하면 좋음

- 이때 지라/트렐로 같은 시스템을 이용하면 테스트 사례를 하위 작업으로 등록해서 테스트 통과 여부 추적 가능

하나씩 성공시켜나가는 형식으로 짧은 개발 리듬을 잡고 가는 것이 더 효율적인 방식

테스트 코드 구현에서 막혔을 경우 단언/검증 코드부터 하나씩 만들어가보는 것이 좋음

TDD 시작하기

codingtori — Tue, 9 Sep 2025 12:42:21 +0900

나는 IntelliJ와 Maven을 이용해서 할 예정이다...!

일단 먼저 JUnit 설정을 해야하는데,

프로젝트 하나를 새로 생성해주고, JUnit5 라이브러리를 추가해주면 된다.

라이브러리 추가의 경우,

[File] → [Project Structrue ...] 메뉴를 통해서 생성해주면 된다

org.juni.jupiter:junit-jupiter:5.5.0 을 입력하라고 하는데, 이렇게 하면 Found:0 으로 검색이 안된다....

따라서, 아래와 같이 검색해주어야 한다.

그리고 클래스를 추가해서 테스트 코드를 실행하면, 잘 실행이 되는 것을 확인할 수 있다.

이제 메이븐 프로젝트에서 JUnit을 설정해보자.

이를 위해서 pom.xml 파일에 JUnit5를 위한 의존성을 추가해주어야 한다.

TDD : Test-Driven Development (테스트 주도 개발)

기능을 검증하는 테스트 코드를 먼저 작성하고 테스트를 통과시키기 위해 개발을 진행하는 것

[ example1_계산기 예제 ]

assertEquals() : 인자로 받은 두 값이 동일한지 비교

- 사용 방법 : assertEquals(기대값, 실제값)

- 일치하지 않는 경우 : AssertionFailedError 발생

인스턴스 메소드 VS 정적 메소드

● 인스턴스 메소드

객체를 생성해야 됨

● 정적 메소드

+) src/test/java/ 소스 폴더는 배포 대상에서 제외됨

테스트 → 코딩 → 리팩토링 : 이 과정을 계속 반복한다

TDD의 이점 : 코드 수정에 대한 피드백이 빠름 → 잘못된 코드가 배포 되는 것 방지 가능

첫 번째 테스트

- 가장 쉽거나 가장 예외적인 상황을 선택해야함

: 모든 조건을 충족하는 경우

두 번째 테스트

- 패스워드 문자열의 길이가 8글자 미만, 나머지 조건은 충족 == 암호 강도: 보통

세 번째 테스트

- 숫자를 포함하지 않고 나머지 조건은 충족하는 암호 == 암호강도: 보통

네 번째 테스트

- 값이 없는 경우 NPE(Null Pointer Exception) 발생

해결하기 위해서는

- IllegalArgumentException 발생 / PasswordStrength.INVALID 설정

다섯 번째 테스트

- 대문자 포함하지 않고 나머지 조건을 충족하는 경우

이렇게 까지 하면 한 가지 조건만 충족하거나 모든 조건을 충족하지 않는 경우만 남음

여섯 번째 테스트

- 길이가 8글자 이상인 조건만 충족

일곱 번째 테스트

- 숫자 포함 조건만 만족함

여덟 번째 테스트

- 대문자 포함 조건만 충족

일일이 테스트마다 로직을 따로 if문으로 분기한다면, 코드 길이도 길어지고 가독성도 떨어짐

=> 공통적인 부분이 뭘까?? => 조건 충족 개수로 묶으면 어떨까?

아홉 번째 테스트

- 아무 조건도 충족하지 않은 경우

완성!

스프링 데이터 JPA

codingtori — Sun, 17 Aug 2025 23:35:17 +0900

스프링 데이터 JPA = 스프링 프레임워크에서 JPA를 편리하게 사용할 수 있도록 지원하는 프로젝트

CRUD를 처리하기 위한 공통 인터페이스 제공

org.springframework.data.jpa.repository.JpaRepository

리포지토리 개발 시, 인터페이스만 작성하면 실행 시점에 스프링 데이터 JPA가 구현 객체를 동적으로 생성해서 주입해줌

➡️ 데이터 접근 계층을 개발 시, 구현 클래스 없이 인터페이스만 작성해도 개발 완료 가능

스프링 데이터 JPA를 사용하기 위해서는 'spring-data-jpa' 라이브러리가 필요함

스프링 데이터 프로젝트

- 스프링 데이터 JPA는 스프링 데이터 프로젝트의 하위 프로젝트들 중 하나. 이는 다양한 데이터 저장소에 대한 접근을 추상화하여 개발자의 편의를 제공하고 지루하게 반복하는 데이터 접근 코드를 줄여줌

공통 인터페이스 기능

스프링 데이터 JPA는 간단한 CRUD 기능을 공통으로 처리하는 JpaRepository 인터페이스 제공

사용방법

JpaRepository 인터페이스를 상속받은 후 제네릭에 엔티티 클래스와 엔티티 클래스가 사용하는 식별자 타입을 지정하면 됨

주요 메소드

save(S) : 새로운 엔티티는 저장하고 이미 있는 엔티티는 수정함
delete(T) : 엔티티 하나를 삭제함. 내부에서 EntityManager.remove() 호출
findOne(ID) : 엔티티 하나를 조회함. 내부에서 EntityManager.find() 호출
getOne(ID) : 엔티티를 프록시로 조회함. 내부에서 EntityManager.getReference() 호출
findAll(...) : 모든 엔티티 조회. 정렬(Sort)이나 페이징(Pageable) 조건을 파라미터로 제공가능

쿼리 메소드 기능

스프링 데이터 JPA가 제공하는 마법 같은 기능

메소드 이름으로 쿼리 생성
메소드 이름으로 JPA NamedQuery 호출
@Query 어노테이션을 사용해서 리포지토리 인터페이스에 쿼리 직접 정의

1. 메소드 이름으로 쿼리 생성

예를 들어, 인터페이스에 'findByEmailAndName(...)' 메소드를 실행하면 스프링 데이터 JPA는 메소드 이름을 분석해서 JPQL 생성 후 실행

2. JPA Named Query

메소드 이름으로 JPA Named 쿼리를 호출하는 기능 제공. JPA Named Query = 쿼리에 이름을 부여해서 사용하는 방법

@NamedQuery 사용

3. @Query 사용

리포지토리 메소드에 직접 쿼리를 정의하는 것 (org.springframework.data.jpa.repository.Query 사용)

이름없는 Named 쿼리 = 실행할 메소드에 정적 쿼리를 직접 작성, 애플리케이션 실행 시점에 문법 오류 발견 가능

파라미터 바인딩

스프링 데이터 JPA는 위치 기반 파라미터 바인딩과 이름 기반 파라미터 바인딩을 모두 지원

위치 기반 : select m from Member m where m.username = ?1
이름 기반 : select m from Member m where m.username= :name

기본값은 위치 기반인데 파라미터 순서로 바인딩

+++++

정렬 : org.springframework.data.domain.Sort

페이징 : org.springframework.data.domain.Pageable (내부에 sort가 포함되어 있음)

사용자 정의 리포지토리 구현

사용자 정의 인터페이스 작성 → 사용자 정의 인터페이스를 구현한 클래스 작성 (리포지토리 인터페이스 이름 + Impl) → 리포지토리 인터페이스에서 사용자 정의 인터페이스 상속받기