dpdpdndn 블로그

BE-20-e2e-scenario-test

NEW9 min read

[BE-20] E2E 시나리오 통합 테스트

작업 내용 (설계 의도)

근거 TDD: 20260722-타깃-공고-알림-및-지원-히스토리-tdd.md — “Testing Plan”

변경 사항

컨텍스트를 가로지르는 전체 비즈니스 플로우를 Testcontainers(MySQL) 기반 시나리오 테스트로 검증합니다. 각 티켓의 단위·통합 테스트는 자기 경계 안만 보므로, 경계를 넘는 순간의 오류(시딩 플래그가 알림 대상 산출까지 전파되는지, 이벤트 유실이 스윕으로 흡수되는지, 소스 가드가 실제로 CLOSED를 막는지)는 여기서만 잡힙니다.

검증할 시나리오 (PRD User Scenarios 대응):

#시나리오대응
1회사 등록 → 소스 확정 → 수집 대상 포함시나리오 1
21회차 수집(시딩, 알림 없음) → 2회차 수집(신규 발견) → 09:00 발송시나리오 2
3지원 생성 → 서류전형 → 면접 회차 추가 → 처우협의 → 최종 합격 + 히스토리 조회시나리오 3
4소스 3일 연속 0건 → 마감 판정 skip 확인 + 고장 알림 발송시나리오 4
5후보 0건 → MANUAL_ONLY 등록 → 수동 공고 등록 → 지원 연결시나리오 5
6로그인 필요 공고 감지 → 자동 판정 제외 → 수동 등록으로 대체시나리오 6
7웹훅 실패 3회 → 실패 이력 조회 → 다음 배치 재발송 성공시나리오 7
8애그리게이터 수집 → 미등록 회사 DISCOVERED 자동 등록 → 매칭 공고가 개별이 아닌 일일 요약에 포함시나리오 9
9같은 공고가 회사 직접 소스·애그리게이터 양쪽 수집 → dedup 대표 선정(직접 우선) → 신규 알림 1회만시나리오 10

외부 의존(채용 소스 5종·디스코드 웹훅)은 MockWebServer + 고정 fixture로 대체합니다. 시간 의존 로직은 스케줄러를 직접 호출하는 대신 UseCase를 호출해 결정적으로 검증합니다(ZonedDateTime.now()를 도메인 내부에서 해결하는 컨벤션상 Clock을 주입하지 않으므로, 시각 검증은 결과 필드의 범위 검증으로 처리합니다).

이 티켓은 프로덕션 코드를 수정하지 않습니다 — 테스트 소스만 추가해 Single Writer per File을 유지합니다. 시나리오 검증 중 결함이 발견되면 해당 티켓 담당자에게 수정을 요청합니다.

의존

  • BE-10, BE-13, BE-14, BE-15, BE-16, BE-17, BE-18, BE-24(dedup), BE-25(애그리게이터 수집·자동 등록)

다이어그램

처리 흐름

sequenceDiagram
    participant T as 시나리오 테스트
    participant Api as REST API
    participant Col as 수집 UseCase
    participant Ev as 평가 UseCase
    participant No as 발송 UseCase
    T->>Api: 회사 등록 (소스 확정)
    T->>Col: 1회차 수집 (시딩)
    T->>No: 발송 실행 → 0건 검증
    T->>Col: 2회차 수집 (신규 1건)
    T->>Ev: 평가 (매칭 성공)
    T->>No: 발송 실행 → 1건 발송 검증
    T->>Api: 지원 생성 → 상태 전이 → 면접 추가
    T->>Api: 히스토리 조회 → 이력 순서 검증

클래스 의존

flowchart LR
    subgraph Test["src/test/scenario"]
        S1[CompanyRegistrationScenario]
        S2[CollectionToNotificationScenario]
        S3[ApplicationLifecycleScenario]
        S4[SourceFailureScenario]
        S5[ManualPostingScenario]
    end
    subgraph Fixture["테스트 지원"]
        Mock[MockWebServer]
        TC[Testcontainers MySQL]
        Fx[소스 응답 fixture]
    end
    S1 --> Mock
    S2 --> Mock
    S2 --> Fx
    S3 --> TC
    S4 --> Mock
    S5 --> TC
    S1 --> TC

테스트 케이스

  • 회사 등록 → 소스 확정 후 수집 대상 조회에 해당 소스가 포함된다
  • 1회차 수집(시딩) 후 발송 실행 시 알림이 0건이다
  • 2회차 수집에서 신규 공고 1건이 발견되고 발송 실행 시 1건이 발송된다
  • 매칭되지 않는 공고는 저장되지만 발송 대상에서 제외된다
  • 지원 생성 → DOCUMENT_SCREENING → 면접 회차 2건 추가 → INTERVIEWING → OFFERED → ACCEPTED 전체 경로가 성공하고 히스토리가 총 5건(생성 1 + 전이 4) 순서대로 조회된다
  • 각 단계에서 응답의 allowedNextStatuses가 현재 상태의 허용 전이와 일치하고, 종료 상태에서 빈 배열이 된다
  • 수집으로 저장된 본문·태그만으로 키워드 변경 후 재매칭이 완주하며 소스를 재호출하지 않는다
  • 지원 목록 조회 시 companyName·jobPostingTitle이 채워져 무엇에 지원했는지 식별된다
  • 공고 목록 응답만으로 매칭 여부·지원 여부·근무형태 라벨이 확인되어 상세를 추가 호출하지 않는다
  • OFFERED에서 WITHDRAWN 전이 시도가 409로 거부된다
  • 소스가 3일 연속 0건을 반환해도 기존 공고가 CLOSED되지 않는다 (소스 가드)
  • 3일 연속 0건 후 소스 고장 알림이 1건 발송된다
  • 후보 0건 회사를 MANUAL_ONLY로 등록하고 수동 공고를 추가한 뒤 지원을 연결할 수 있다
  • 수동 공고는 이후 수집 회차에서 미발견 카운터가 증가하지 않는다
  • 로그인 필요 공고가 접근 제한으로 표시되고 자동 마감 판정 대상에서 제외된다
  • 웹훅이 3회 실패하면 실패 이력이 조회되고, 다음 발송 실행에서 재발송에 성공하며 그때 멱등 키가 채워진다
  • 평가 이벤트가 유실된 상황을 재현해도 보정 스윕 실행 후 발송 대상에 포함된다
  • 마감일이 지난 공고가 마감일 경과 배치로 CLOSED되고, 상시채용 공고는 유지된다
  • CLOSED 공고가 재발견되면 OPEN으로 복귀하되 신규 알림이 발송되지 않는다
  • 애그리게이터 수집에서 미등록 회사가 DISCOVERED로 자동 등록되고 그 매칭 공고가 일일 요약 1건으로 발송된다
  • 회사 직접 소스와 애그리게이터에서 같은 공고를 수집하면 dedup 후 직접 소스가 대표가 되고 신규 알림이 1회만 발송된다
  • 애그리게이터본이 먼저 대표로 알림된 뒤 직접본이 등장해 대표가 바뀌어도 추가 알림이 없다
  • 잡코리아 어댑터가 허용 경로 외(키워드 검색)를 호출하면 규약 정책이 예외로 차단한다(회색지대 규약 강제 검증)
  • 리멤버 어댑터가 2회차부터 min_updated_at 증분으로 수집한다
  • CLOSED 공고도 크로스 소스 dedup 그룹에 남고 대표 선정 시 OPEN이 우선된다

그래프 뷰