Mock, Stub 의 차이

mock과 stub은 테스트에서 외부 의존성을 대체하기 위해 쓰이는 객체인데, 둘은 목적과 기능 면에서 조금 달라요.

📌 요약 비교

🔹 Stub: 단순하게 리턴값만 정해놓은 가짜

• 실제 메서드 로직은 필요 없고, “이 값을 주면 이 값을 돌려줘!” 같은 간단한 대체품.
• 주로 “기존 시스템에서 이거만 제대로 동작하면 돼"라는 테스트에 사용.

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

🔸 Mock: 행위(호출 여부 등)까지 확인하는 가짜

• 리턴값도 정의할 수 있지만, “정말로 이 메서드가 호출됐는가?” 같은 검증도 가능.
• verify() 같은 메서드를 통해 테스트의 정확성을 높임.

verify(userRepository, times(1)).findById(1L);

✅ 실제 테스트 예시

@Mock
UserRepository userRepository;

@InjectMocks
UserService userService;

@Test
void testUserFetch() {
    // Stub: 리턴값 지정
    when(userRepository.findById(1L)).thenReturn(Optional.of(new User("Alice")));

    // 메서드 실행
    User user = userService.getUser(1L);

    // Mock: 호출 여부 검증
    verify(userRepository, times(1)).findById(1L);
}

📎 간단 비유

• Stub: “누가 와도 무조건 이 대사만 말해!”
• Mock: “누가 오면 이 대사를 하고, 제대로 말했는지 검사도 합니다.!”

테스트 더블(Test Double) 용어 정리

• 아래는 테스트에서 자주 쓰이는 5가지 테스트 대역입니다:

🧪 테스트 더블(Test Double) 종류 요약

1. 🐣 Dummy

• 가장 단순한 형태.
• 아무 일도 하지 않고, 값만 채우는 용도.
• 테스트에 직접적 의미 없음. 없어도 테스트 통과 가능.

User dummyUser = new User(null); // 생성자 매개변수 맞추려고 넣는 용도

2. 🧪 Stub

• 호출하면 정해진 값을 리턴함.
• 동작 자체는 단순하고 검증 로직은 없음.
• 상태 기반 테스트에 사용됨.

when(userRepository.findById(1L)).thenReturn(Optional.of(new User("Alice")));

3. 🤖 Mock

• Stub처럼 리턴값을 줄 수 있지만, 추가로 호출 여부도 검증함.
• 테스트의 **행위 검증(Behavior Verification)**에 초점.

verify(userRepository, times(1)).save(any());

4. 🕵️ Spy

• 실제 객체를 감싸면서, 필요한 부분만 mock 처리 가능.
• 일부 메서드는 진짜 실행, 일부는 stub/mock 가능.
• 사용 시 조심: 진짜 의존성이 따라올 수 있음.

UserService spyService = spy(new UserService(realRepository));
doReturn("fakeName").when(spyService).getUserName();

5. 🧩 Fake

• 진짜 구현체는 아니지만, 실제로 동작하는 간단한 구현.
• 테스트용으로 가볍게 만든 진짜 비즈니스 로직을 흉내낸 것.
• 예: InMemory DB, 테스트용 메시지 큐 등

public class InMemoryUserRepository implements UserRepository {
    private Map<Long, User> db = new HashMap<>();
    public Optional<User> findById(Long id) { return Optional.ofNullable(db.get(id)); }
}

🎯 어떤 걸 언제 써야 할까?

Fake Repository 예시

Spring 환경에서 자주 쓰이는 Fake Repository 예제를 보여드릴게요.
단위 테스트에서 JPA 같은 실제 DB 연결 없이도 로직을 검증하고 싶을 때 아주 유용합니다.

MSA(Microservices Architecture)에서 trace ID와 span ID는 **분산 추적(distributed tracing)**에서 사용되는 고유 식별자들이야. 시스템 전체에서 요청의 흐름을 추적할 수 있게 해주는 핵심 개념입니다.

1. Trace ID

• 하나의 전체 요청(Request)을 식별하는 고유한 ID입니다.
• 예: 사용자가 웹에서 어떤 버튼을 클릭해서 API 요청이 들어오고, 그 요청이 여러 개의 마이크로서비스를 거쳐 처리되는 경우, 이 전체 흐름을 하나의 trace로 봅니다.
• 즉, trace ID는 **“이 요청이 어디서 시작돼서 어디까지 갔는가”**를 나타냄.

2. Span ID

• trace 안에서 **각각의 작업 단위(작은 호출 하나하나)**를 식별하는 ID입니다.
• 예: A 서비스가 B 서비스와 C 서비스를 호출하면, A-B, A-C 각각이 별도의 span이 되고, 각각에 대한 span ID가 있습니다.
• Span은 시작 시간, 종료 시간, 어떤 작업인지 등 세부 정보도 포함됩니다.

구조 예시

[Trace ID: abc123]

   ┌─────────────┐       ┌─────────────┐
   │ User Request│──────▶│ API Gateway │───┐
   └─────────────┘       └─────────────┘   │
                                           ▼
                                   ┌────────────┐
                                   │ Service A  │───┐
                                   └────────────┘   │
                                                    ▼
                                            ┌────────────┐
                                            │ Service B  │
                                            └────────────┘

• 전체 요청의 흐름이 하나의 Trace ID (abc123)를 공유하고,
• 각 서비스 간 호출은 서로 다른 Span ID를 가짐.

요약

첨언

• 실제 MSA 구현시 front end에서 api request시점부터 trace id와 span id가 채번되고
• 예를 들어, bff -> api-gateway -> user-service 를 통해 request 가 흘러간다면, 각 서비스는 동일한 trace id로 추적이 되어야 합니다.

JVM(Java Virtual Machine)에서는 내부적으로 여러 종류의 스택(stack) 을 사용합니다. 각각의 스택은 JVM의 실행 및 메모리 관리 등에서 중요한 역할을 합니다. 주요 스택 종류는 다음과 같습니다:

🧠 1. Java Virtual Machine Stack (또는 Thread Stack)

• 설명: 각 스레드(thread) 마다 하나씩 존재하는 스택입니다.
• 역할: 메서드 호출 시 생성되는 스택 프레임(stack frame) 을 저장합니다. 각 프레임에는:
  • 지역 변수(Local Variables)
  • 피연산자 스택(Operand Stack)
  • 메서드 반환 주소 등이 포함됨
• 예외: 스택 오버플로우 발생 시 StackOverflowError 발생

🔁 2. Native Method Stack

• 설명: 네이티브 메서드(C로 구현된 JNI 메서드 등) 호출 시 사용되는 스택입니다.
• 역할: C/C++ 등 JVM 외부 언어로 구현된 메서드에서 필요한 데이터를 저장
• 특이사항: 일부 JVM 구현에서는 Java 스택과 통합되기도 함

💾 3. Operand Stack (피연산자 스택)

• 설명: 위의 JVM Stack의 각 스택 프레임 내에 존재하는 스택입니다.
• 역할: 바이트코드 명령어가 실행 중인 중간 연산 결과를 임시로 저장
• 예시: iadd, imul 같은 바이트코드 명령은 이 스택에서 피연산자를 꺼내 계산

🧱 4. Call Stack (호출 스택)

• 설명: JVM Stack의 구조적인 측면을 지칭하는 용어로, 메서드 호출의 흐름을 나타냅니다.
• 역할: 현재 실행 중인 메서드부터 시작해 호출된 메서드들이 차곡차곡 쌓여 있음
• 특징: 디버깅 시 “Stack Trace"로 확인 가능

추가로 JVM에는 스택 이외에도 다음과 같은 메모리 영역이 있습니다:

JVM(Java Virtual Machine)에서 heap 메모리는 자바 애플리케이션이 런타임 시 동적으로 생성하는 객체들이 저장되는 영역입니다. 즉, new 키워드를 사용해서 생성하는 대부분의 객체들이 이 영역에 저장됩니다.

📌 Heap 메모리 구성

Heap은 크게 다음 두 영역으로 나뉩니다:

• Young Generation (Young Gen): 새로 생성된 객체가 저장되는 곳.
  • Eden: 대부분의 새 객체가 여기에 생성됨.
  • Survivor: Eden에서 살아남은 객체들이 이동.
• Old Generation (Tenured Gen): Young Gen을 거쳐 오래 살아남은 객체들이 이동하는 공간.

Garbage Collector(GC)는 이 heap 영역의 객체들을 주기적으로 검사해서 더 이상 참조되지 않는 객체는 메모리에서 제거합니다.

@Cacheable 어노테이션은 Spring Framework에서 메서드의 반환값을 캐시에 저장하여, 같은 인자가 들어올 경우 캐시된 값을 재사용하도록 하는 기능을 제공합니다. 즉, 메서드를 반복적으로 호출하더라도 실제로는 처음 한 번만 실행되고, 이후 호출은 캐시된 결과를 반환하게 됩니다.

📌 주요 역할 요약

• 중복 호출 방지: 동일한 입력값에 대해 메서드를 반복 호출하면, 캐시된 결과를 반환해 성능 향상.
• 결과 저장: 메서드 실행 결과를 캐시에 저장.
• 조건부 캐싱: 특정 조건에 따라 캐싱 여부 제어 가능.

✅ 기본 사용 예시

@Cacheable("users")
public User findUserById(Long id) {
    // 실제로는 DB나 외부 API 호출
    return userRepository.findById(id).orElse(null);
}

• 위 메서드는 users라는 캐시 이름으로 결과를 저장합니다.
• id가 동일한 경우, 이후 호출은 캐시된 User 객체를 반환합니다.

🔧 주요 속성

예시:

@Cacheable(value = "books", key = "#isbn", unless = "#result == null")
public Book findBook(String isbn) {
    return bookRepository.findByIsbn(isbn);
}

🧠 함께 알아두면 좋은 어노테이션

• @CachePut : 캐시를 강제로 업데이트할 때 사용
• @CacheEvict : 캐시를 삭제할 때 사용
• @Caching : 여러 캐시 어노테이션을 함께 사용할 때

필요하다면 Redis나 Caffeine 같은 캐시 스토어와 함께 연동도 가능합니다.