클린 아키텍처를 거꾸로 알고 있었어요 — 험블 객체라는 렌즈로 다시 본 테스트 전략

들어가며: 한 번도 의심하지 않았던 그림

"DB가 중심에 있고, 그 위에 도메인이 올라가고, 그 위에 서비스가 올라가고, 가장 바깥에 UI가 있다."

방향이 반대였다

        ┌─────────────────────────────┐
        │  Frameworks & Drivers       │  ← 웹·UI·DB·장치
        │  ┌───────────────────────┐  │
        │  │  Interface Adapters   │  │  ← 컨트롤러·프레젠터·게이트웨이
        │  │  ┌─────────────────┐  │  │
        │  │  │  Use Cases      │  │  │  ← 애플리케이션 업무 규칙
        │  │  │  ┌───────────┐  │  │  │
        │  │  │  │ Entities  │  │  │  │  ← 엔터프라이즈 업무 규칙
        │  │  │  └───────────┘  │  │  │
        │  │  └─────────────────┘  │  │
        │  └───────────────────────┘  │
        └─────────────────────────────┘

• 엔티티(이자 계산 공식)는 유스케이스(대출 신청 플로우)를 모르고요.
• 유스케이스는 UI · DB · 프레임워크를 모릅니다.
• 안쪽이 바깥을 모를수록, 업무 규칙은 기술 결정에 얽매이지 않아요.

어댑터, 또는 험블 객체

한 줄로 줄이면: "비즈니스 로직만 테스트하라"

테두리는 통합 테스트로 가볍게 두고, 안쪽 비즈니스 로직만 단위 테스트로 풍부하게 한다.

• 화면(View)이 험블 껍질이에요. 사용자와 닿은 자리, 자주 바뀌는 자리.
• 그 안쪽에는 — 잘 안 보였지만 분명히 존재하는 — 결정 로직이 있어요. 도메인 모델을 화면이 그릴 수 있는 모양으로 변환하는 자리, 즉 프레젠터.

그래서, 어떻게 테스트할 것인가

1. 인터페이스로 경계를 긋는다.
2. 얇은 껍질(험블)은 통합 테스트로 최소한만 확인한다.
3. 안쪽 로직은 Fake/Stub으로 주입받아, 단위 테스트로 풍부하게 검증한다.

1) DB 테스트: 인터페이스 뒤에 ORM을 가둔다

// 경계 = 인터페이스
interface UserRepository {
  findById(id: string): Promise
}

// 얇은 껍질 (험블)
class PrismaUserRepo implements UserRepository {
  async findById(id: string) {
    return prisma.user.findUnique({ where: { id } })
  }
}

// 테스트 대상 = 안쪽 로직
test('비활성 유저 차단', () => {
  const fake: UserRepository = {
    findById: async () => ({ id: 'u1', active: false } as User),
  }
  const svc = new AuthService(fake)
  expect(() => svc.login('u1')).toThrow('inactive')
})

2) 외부 API 테스트: 네트워크를 어댑터 뒤로 숨긴다

// 경계 = 인터페이스
interface PaymentGateway {
  charge(amount: number): Promise
}

// 얇은 껍질 (험블)
class HttpPaymentGateway implements PaymentGateway {
  async charge(amount: number) {
    const res = await fetch(/* ... */)
    return res.json()
  }
}

// 테스트 대상 = 안쪽 유스케이스
test('결제 실패 시 주문 취소', async () => {
  const stub: PaymentGateway = {
    charge: async () => { throw new Error('declined') },
  }
  const uc = new OrderUseCase(stub)
  await uc.place(order)
  expect(order.status).toBe('cancelled')
})

3) 프론트엔드 테스트: 화면은 그리기만, 결정은 프레젠터에서

// 경계 = 출력 모델
type OrderView = {
  totalLabel: string                          // '₩12,000'
  statusBadge: '결제 대기' | '배송 중' | '취소'
  primaryAction: '결제하기' | '배송 조회' | null
}

// 안쪽 = Presenter (테스트 대상)
function presentOrder(order: Order): OrderView {
  return {
    totalLabel: `₩${order.total.toLocaleString()}`,
    statusBadge: toBadge(order.status),
    primaryAction: pickAction(order),
  }
}

// 얇은 껍질 (험블) = View
function OrderCard({ view }: { view: OrderView }) {
  return (
    
      {view.totalLabel}
      {view.statusBadge}
      {view.primaryAction && {view.primaryAction}}
    
  )
}

// 테스트 = Presenter의 결정
test('미결제 주문은 결제 버튼을 노출한다', () => {
  const order = { total: 12000, status: 'pending', paid: false }
  expect(presentOrder(order).primaryAction).toBe('결제하기')
})

test('취소된 주문은 액션 버튼을 노출하지 않는다', () => {
  const order = { total: 12000, status: 'cancelled', paid: false }
  const view = presentOrder(order)
  expect(view.primaryAction).toBeNull()
  expect(view.statusBadge).toBe('취소')
})

같은 모양의 세 사례 — 정리

테두리는 얇게, 안쪽은 풍부하게.

닫는 말