Загружаем каталог…
Загружаем каталог…
수신자 등록부터 실제 SMTP 발송까지 진짜 한 번에 잘 이어질까? 단위 테스트에서는 각 기능을 따로 확인할 수 있었다. 근데 실제로는 수신자 등록 ↓ 공지 변경 감지 ↓ 알림 후보 생성 ↓ 수신자 조회 ↓ SMTP 발송 ↓ 발송 결과 저장 이 흐름이 전부 연결돼야 한다. 그래서 이번에는 실제 SMTP를 사용하는 통합 테스트를 하나 만들었다. 실제 공지를 쓰는 건 좀 아닌 것 같았다 처음에는 실제 PIA 공지를 하나 가져와서 테스트할 수도 있었다. 근데 그렇게 하면 테스트할 때마다 실제 공지 데이터와 발송 이력이 섞일 수 있다. 잘못하면 기존 baseline이나 알림 기록까지 건드릴 수도 있었다. 메일은 실제로 보내되 데이터는 테스트용으로 따로 만들자. 그래서 테스트 전용 H2 DB를 사용했다. @SpringBootTest(properties = { "spring.datasource.url=jdbc:h2:mem:notification-subscriber-smtp-live;DB_CLOSE_DELAY=-1", "external-notice.scheduler.enabled=false" }) 스케줄러도 꺼두었다. 테스트 중에 자동 수집까지 같이 실행될 필요는 없었기 때문이다. 공지도 실제 포털 데이터를 쓰지 않고 테스트용 공지를 직접 만들었다. ExternalNotice testNotice = notice( externalId, fingerprint, "Biz Assist PIA 알림 SMTP 통합 테스트" ); 이렇게 하면 실제 SMTP 연결은 확인하면서도 기존 데이터와는 분리해서 테스트할 수 있다. 수신자 등록도 API부터 시작했다 이번 테스트에서는 DB에 수신자를 바로 넣지 않았다. 실제로 사용할 때와 최대한 비슷하게 확인하고 싶었다. 그래서 수신자 등록 API부터 호출했다. mockMvc.perform(post("/api/notification-subscribers") .contentType(MediaType.APPLICATION_JSON) .content(json)) .andExpect(status().isCreated()); 등록된 수신자가 실제 활성 수신자로 조회되는지도 확인했다. List<NotificationSubscriber> subscribers = subscriberService.findEnabled( NotificationType.PIA_EXTERNAL_NOTICE ); assertEquals(1, subscribers.size()); 여기까지 되면 적어도 API 등록 → DB 저장 → 활성 수신자 조회 까지는 실제 흐름대로 연결된 셈이다. 첫 수집에서는 메일이 가면 안 된다 이 테스트에서도 기존에 만들었던 baseline 정책을 그대로 확인했다. 처음 수집한 공지는 기준점만 만들고 알림 후보를 만들지 않는다. NoticeChangeResult baselineChange = changeService.process(notice( "baseline-" + inputs.runToken(), "baseline-" + inputs.runToken(), "PIA SMTP baseline fixture" )); assertTrue( notificationService .createCandidates(collectionResult(baselineChange)) .isEmpty() ); 이 부분을 빼고 바로 새 공지를 넣으면 메일이 발송되는지만 볼 수는 있다. 근데 실제 Biz Assist의 흐름과는 다르다. 메일 기능만 확인하는 게 아니라 지금까지 만든 알림 정책까지 같이 확인하고 싶었다. 그래서 baseline부터 거치도록 했다. 그다음 새 공지를 만들었다 baseline이 만들어진 뒤에는 새로운 PIA 공지를 하나 넣었다. NoticeChangeResult newChange = changeService.process(testNotice); assertEquals( NoticeChangeType.NEW, newChange.getChangeType() ); 이 공지에서는 알림 후보가 하나 만들어져야 한다. 그리고 아직 메일을 보내기 전이니까 상태는 PENDING 이어야 한다. List<ExternalNoticeNotificationCandidate> candidates = notificationService.createCandidates( collectionResult(newChange) ); assertEquals(1, candidates.size()); NotificationDelivery pending = findDelivery(candidates.getFirst().getDeliveryId()); assertEquals( NotificationDeliveryStatus.PENDING, pending.getStatus() ); 이제 진짜 발송만 남았다. 실제 SMTP로 보내봤다 발송은 기존 NotificationDispatcher 를 그대로 사용했다. NotificationDispatchResult firstDispatch = dispatcher.dispatchPending(); 그리고 결과를 확인했다. assertEquals(1, firstDispatch.sentCount()); assertEquals(0, firstDispatch.failedCount()); 알림 이벤트도 SENT . 수신자별 발송 이력도 SENT . 둘 다 확인했다. assertEquals( NotificationDeliveryStatus.SENT, sentEvent.getStatus() ); assertEquals( NotificationDeliveryStatus.SENT, subscriberDelivery.getStatus() ); 여기서 중요한 건 단순히 SMTP 메일 한 통을 보내본 게 아니라 수신자 등록부터 실제 발송 이력 저장까지 전부 연결해서 확인했다는 것 이다. 두 번 실행하면 또 보내지 않을까? 실제 메일을 보내는 테스트라서 이것도 확인해야 했다. 한 번 성공한 알림을 다시 실행했을 때 같은 메일이 또 가면 안 된다. 그래서 같은 상태에서 dispatchPending() 을 한 번 더 실행했다. NotificationDispatchResult duplicateDispatch = dispatcher.dispatchPending(); assertEquals(0, duplicateDispatch.pendingCount()); assertEquals(0, duplicateDispatch.sentCount()); assertEquals(0, duplicateDispatch.failedCount()); 수신자별 발송 기록도 하나만 남아 있는지 확인했다. assertEquals( 1, subscriberDeliveryRepository .findByNotificationDeliveryId(deliveryId) .size() ); 실제 SMTP까지 연결된 상태에서도 중복 발송이 막히는지 확인한 셈이다. 근데 이 테스트를 매번 실행하면 안 된다 이건 실제 메일을 보내는 테스트다. 일반 테스트 실행할 때마다 메일이 날아가면 곤란하다. 그래서 환경변수를 명시적으로 켰을 때만 실행하도록 했다. @EnabledIfEnvironmentVariable( named = "BIZ_ASSIST_SUBSCRIBER_SMTP_LIVE_TEST", matches = "true" ) SMTP 계정이나 수신자 정보도 테스트 코드에 직접 넣지 않았다. 필요한 값은 전부 환경변수로 받도록 했다. 테스트할 때만 의도적으로 켜고 평소에는 실행되지 않게 했다. 이제 진짜 한 번 연결해봤다 22편에서는 SMTP 서버로 메일 자체가 발송되는지 확인했다. 23편에서는 수신자를 여러 명 관리하고 발송 결과를 따로 저장하도록 만들었다. 이번에는 그 두 가지를 실제 흐름으로 연결해서 확인했다. 수신자 API 등록 ↓ baseline 생성 ↓ 새 PIA 공지 감지 ↓ 알림 후보 생성 ↓ 실제 SMTP 발송 ↓ 알림 SENT ↓ 수신자별 발송 SENT ↓ 재실행 시 중복 발송 없음 기능을 하나씩 테스트하는 것과 실제로 처음부터 끝까지 한 번 연결해 보는 건 조금 달랐다. 이번에는 “메일을 보낼 수 있다”가 아니라 “Biz Assist의 알림 흐름으로 실제 메일이 한 번만 발송된다”까지 확인했다.
То, что RADAR обнаружил и классифицировал для этой возможности. Это опубликованный источником текст, а не подтверждение, что предложение ещё действует.
테스트는 통과했는데 진짜 메일도 갈까?. 수신자 등록부터 실제 SMTP 발송까지 진짜 한 번에 잘 이어질까? 단위 테스트에서는 각 기능을 따로 확인할 수 있었다. 근데 실제로는 수신자 등록 ↓ 공지 변경 감지 ↓ 알림 후보 생성 ↓ 수신자 조회 ↓ SMTP 발송 ↓ 발송 결과 저장 이 흐름이 전부 연결돼야 한다. 그래서 이번에는 실제 SMTP를 사용하는 통합 테스트를 하나 만들었다. 실제 공지를 쓰는 건 좀 아닌 것 같았다 처음에는 실제 PIA 공지를 하나 가져와서 테스트할 수도 있었다. 근데 그렇게 하면 테스트할 때마다 실제 공지 데이터와 발송 이력이 섞일 수 있다. 잘못하면 기존 baseline이나 알림 기록까지 건드릴 수도 있었다. 메일은 실제로 보내되 데이터는 테스트용으로 따로 만들자. 그래서…
Открыть источник