[📰 위클리페이퍼] 입력 값 검증 범위와 책임 & Mockito

📌 애플리케이션 계층별 입력값 검증

🧐 입력값 검증이란?

애플리케이션에 들어오는 데이터가 올바른지 확인하는 과정

단순히 null 체크만 하는 게 아니라

• 요청 형식이 맞는지
• 값의 범위가 적절한지
• 비즈니스 규칙을 만족하는지

👉 다양한 수준의 검증이 존재함

🤔 왜 계층별로 나눠야 할까?

한 군데에서만 검증하면?

👉 다른 경로에서 들어오는 데이터는 방어 못 함

반대로 모든 계층에서 검증하면?

👉 중복 코드 증가
👉 유지보수 어려움

👉 그래서 책임을 나눠야 함

⚠️ 계층별 책임

1️⃣ Controller (입력 형식 검증)

"사용자가 보낸 값이 정상적인 형태인가?"

public record CreateUserRequestDTO(
    @NotBlank String email,
    @NotBlank String username
) {}

✔️ 역할

null, 공백 체크
형식 검증 (이메일, 길이 등)

👉 가장 바깥에서 1차 필터링

2️⃣ Service (비즈니스 검증)

"이 값이 서비스 규칙에 맞는가?"

if (userRepository.existsByEmail(email)) {
    throw new DuplicateEmailException();
}

✔️ 역할

중복 검사
상태 검증
권한 체크

👉 "이게 가능한 요청인가?"를 판단

3️⃣ Domain / Entity (불변성 보장)

"이 객체는 항상 유효한 상태인가?"

public void changeName(String name) {
    if (name == null || name.isBlank()) {
        throw new IllegalArgumentException();
    }
    this.name = name;
}

✔️ 역할

객체 자체의 유효성 유지
잘못된 상태 생성 방지

👉 마지막 방어선

🔥 중복 검증 없이 안정성 확보하는 방법

👉 핵심 전략

Controller → "형식 검증"
Service → "비즈니스 검증"
Entity → "불변성 보장"

👉 같은 검증을 여러 번 하지 않는다

예시 ❌ (잘못된 구조)

Controller에서 null 체크
Service에서도 null 체크
Entity에서도 null 체크

👉 완전 중복

예시 ⭕

Controller: @NotBlank
Service: 중복 이메일 검사
Entity: 상태 보장

👉 역할 분리 완료

⚖️ 트레이드오프

1️⃣ 중복 제거 vs 안정성

검증을 줄이면 → 코드 깔끔 👍
검증을 늘리면 → 안전성 ↑ 👍

👉 선택 필요

2️⃣ Entity 검증 강도

강하게 하면 → 안전 👍
너무 강하면 → 유연성 ↓ 👎

👉 DTO → Service → Entity 흐름 중요

3️⃣ 성능 vs 방어

검증 많으면 → 안전 👍
하지만 → 비용 증가 👎

👉 "필요한 만큼만"

🧠 정리

입력값 검증 = 계층별 역할 분리

Controller → 형식 검증
Service → 비즈니스 검증
Entity → 상태 보장

핵심 👉 중복 없이 책임 분리
트레이드오프 👉 안정성 vs 복잡도

---

📌 Mockito의 Mock, Stub, Spy

🧐 Mockito란?

테스트에서 실제 객체 대신 가짜 객체를 사용하는 라이브러리

👉 외부 의존성을 제거하고 테스트를 쉽게 만들어줌

🤔 왜 필요한가?

예를 들어 Service를 테스트할 때

DB 접근
API 호출

👉 이런 것까지 같이 테스트하면

느림
불안정
테스트 어려움

👉 그래서 가짜 객체 사용

⚠️ 개념 정리

1️⃣ Mock

행동을 직접 정의하는 가짜 객체

UserRepository userRepository = mock(UserRepository.class);

when(userRepository.findById(1L))
    .thenReturn(Optional.of(user));

✔️ 특징

아무 동작도 안 함
우리가 정의한 대로만 동작

👉 완전한 가짜

2️⃣ Stub

특정 입력에 대해 미리 결과를 정해둔 것

when(userRepository.existsByEmail("test@test.com"))
    .thenReturn(true);

✔️ 특징

"이 값 넣으면 이 결과 반환"

👉 Mock의 사용 방식 중 하나

3️⃣ Spy

실제 객체 + 일부만 가짜로 덮어쓰기

List<String> list = spy(new ArrayList<>());

list.add("A"); // 실제 동작

doReturn(100).when(list).size(); // 일부만 조작

✔️ 특징

실제 로직 실행됨
일부만 override 가능

👉 반쯤 진짜

🔥 언제 무엇을 써야 할까?

1️⃣ Mock

👉 외부 의존성 제거할 때

예시

Repository
API Client
when(userRepository.findById(1L)).thenReturn(user);

👉 가장 많이 사용

2️⃣ Stub

👉 "결과만 필요할 때"

예시

조건 분기 테스트

when(repo.existsByEmail(email)).thenReturn(true);

👉 로직 흐름 검증

3️⃣ Spy

👉 일부만 테스트하고 싶을 때

예시

복잡한 객체
실제 로직 일부 유지

👉 하지만

⚠️ 남용 금지
→ 테스트가 복잡해짐

⚖️ 트레이드오프

1️⃣ Mock 남용

빠르고 편함 👍
하지만 실제와 다를 수 있음 👎

2️⃣ Spy 사용

현실적 👍
하지만 예측 어려움 👎

3️⃣ Stub 단순함

이해 쉬움 👍
하지만 테스트 범위 제한 👎

🧠 정리

Mock / Stub / Spy 차이

Mock → 완전 가짜
Stub → 결과 정의
Spy → 일부만 가짜

핵심 👉 상황에 맞게 선택