🔧 [Chore] WatchConnectivity 테스트 타겟 · CI watchOS 빌드 검증 (#1216)

[JEONG-J]

🔗 관련 이슈

Closes #1216

✨ PR 유형

chore — 테스트 타겟 신설 + CI 검증 게이트 추가 (부수적으로 드러난 워치 세션 버그 2건 수정)

워치 관련 코드가 테스트도 CI 검증도 전혀 받지 않던 상태였습니다. 회귀를 잡을 그물을 먼저 칩니다.

📷 스크린샷 or 영상(UI 변경 시)

해당 없음 — UI 변경이 없습니다.

🛠️ 작업내용

1. CoreWatchConnectivity 테스트 타겟 추가

Core/WatchConnectivity/Project.swift 를 coreProject(..., includesTests: true) 로 전환했습니다.
3개 스위트 / 17개 테스트가 추가됐고 전부 통과합니다.

스위트	검증 내용
WatchSessionCoordinator — 활성화·reachability 상태 전이	초기 상태, activate() 의 델리게이트 연결 순서, 미지원 기기 no-op, 활성화 성공/실패(.notActivated·.inactive·error 동반), reachability 변경 반영
WatchSessionCoordinator — 전송 계약과 에러 경로	sessionNotActivated·notReachable 차단, 전송 성공 시 정상 반환, 전송 계층 원본 에러 전파, 컨텍스트 갱신 전달/에러 전파
WatchMessenger — 딕셔너리 페이로드 전달 계약	페이로드를 변형 없이 세션까지 넘기는지, 에러가 메신저를 통과해 올라오는지

2. 테스트를 위한 최소 seam — WatchSessionProviding

WatchSessionCoordinator 가 WCSession.default 싱글턴을 직접 잡고 있어서 상태 전이를 결정적으로
재현할 방법이 없었습니다. (WCSession 은 직접 생성할 수 없고, 페어링된 워치가 없으면 isReachable
이 항상 false 라 전송 성공 경로를 아예 밟을 수 없습니다.)

코디네이터가 실제로 쓰는 표면만 추린 얇은 프로토콜을 두고 WCSession 이 준수하도록 했습니다.
프로덕션은 기본 인자 WCSession.default 를 그대로 쓰므로 호출부 변경은 없습니다
(현재 이 모듈의 외부 호출부는 0곳).

프로토콜 메서드 이름을 WCSession 원본과 다르게(startActivation·send·apply) 둔 이유는 코드
주석에 적어뒀습니다 — 동일 시그니처로 선언하면 준수 익스텐션이 자기 자신을 호출하게 되고,
SDK 블록 시그니처가 바뀌면 준수가 조용히 깨집니다. 전달(forwarding)만 하면 그 위험이 없습니다.

3. 테스트를 붙이면서 드러난 실제 버그 3건 수정

• sendMessage(_:) 가 성공 시 영원히 반환하지 않았습니다. replyHandler: nil 로 보내면
  WatchConnectivity 는 실패할 때만 errorHandler 를 호출합니다. 즉 전송이 성공하면
  withCheckedThrowingContinuation 이 영영 재개되지 않아 호출자가 영구 정지합니다.
  replyHandler 를 넘겨 ack 를 받도록 고쳤습니다. 회귀 방지 테스트가 붙어 있습니다.
• activate() 이후 isReachable 이 세션 값으로 초기화되지 않았습니다. 활성화 완료 콜백에서
  isActivated 만 세팅해, reachability 변경 이벤트가 한 번 오기 전까지 실제로 연결돼 있어도
  false 로 보였습니다. 활성화 성공 시점에 세션 값을 동기화합니다.
• WatchConnectivityError.sessionNotActivated 가 선언만 되고 한 번도 던져지지 않는 죽은 케이스
  였습니다. 특히 updateApplicationContext 는 활성화 전에 호출하면 Swift 에러가 아니라 ObjC 예외로
  앱이 죽습니다. 두 메서드 앞에 활성화 가드를 넣어 이 케이스를 살렸습니다.

4. CI watchOS 검증 (.github/workflows/tuist-ci.yml)

기존 build-test 잡 뒤에 3개 스텝을 이어 붙였습니다.

1. Check watchOS simulator runtime — 런타임 존재 확인, 없으면 xcodebuild -downloadPlatform watchOS
   시도. 실패시키지 않고 경고만 남깁니다 (generic 목적지 빌드는 런타임 없이도 통과하는 경우가 많고,
   진짜로 빠졌다면 다음 스텝이 깨지면서 이 로그가 원인을 바로 가리킵니다).
2. Build watchOS app — make build-watch
3. Test CoreWatchConnectivity — make test SCHEME=CoreWatchConnectivity

별도 잡으로 빼지 않은 이유: 시크릿 복원 · mise/Tuist 설치 · SPM 캐시 · tuist generate 를
통째로 한 번 더 돌려야 해서 러너 시간이 두 배가 됩니다. 같은 잡에 이어 붙여 워크스페이스를 재사용합니다.

스킴을 명시해 따로 테스트하는 이유: UMCApp 스킴의 test action 에는 UMCAppTests 만 들어 있어
기존 make test 로는 Core 모듈 테스트가 한 개도 돌지 않습니다.

5. UMCApp/Makefile — make build-watch

WATCH_SCHEME ?= UMCWatchApp / WATCH_DESTINATION ?= generic/platform=watchOS Simulator 추가.

워치 시뮬레이터 기종을 하드코딩하지 않았습니다. 이슈 본문 예시(Apple Watch Series 10 (46mm))는
현재 로컬 머신에 없고(설치된 건 Series 11 / Ultra 3 / SE 3), 러너 이미지와도 다릅니다. 기종을 박으면
한쪽이 반드시 깨지므로 generic 목적지로 컴파일만 검증합니다. 기종 지정이 필요하면
WATCH_DESTINATION 으로 덮어쓸 수 있고 가이드에 예시를 적어뒀습니다.

6. UMCApp/MAKEFILE_GUIDE.md

§2 에 make build-watch 행과 "watchOS 타겟 빌드·테스트" 절, §4 환경 변수 표에 WATCH_SCHEME /
WATCH_DESTINATION 을 추가했습니다.

✅ 검증 결과

make test SCHEME=CoreWatchConnectivity
  → ✔ Test run with 17 tests in 3 suites passed. ** TEST SUCCEEDED **

make build-watch
  → ** BUILD SUCCEEDED **

이슈의 "의도적 컴파일 에러 시 CI 가 실패하는지" 검증도 실제로 돌렸습니다.
UMCWatchApp/Sources/ContentView.swift 에 타입 오류 한 줄을 넣고 make build-watch 를 돌려
error: cannot convert value of type 'String' to specified type 'Int' → ** BUILD FAILED ** 를
확인한 뒤 원복했습니다. 이전에는 이 에러가 CI 를 전혀 건드리지 못했습니다.

📋 추후 진행 상황

• 페이로드 Codable 인코딩/디코딩 테스트는 이번 PR 범위에 없습니다. 이슈 완료 조건에 있지만,
  선행 이슈(✨ Feature: Watch 디자인 토큰·공통 컴포넌트 구축 (Glass 절제 규칙) #1205~✨ Feature: Watch Complication 3종 (WidgetKit accessory family) #1215)의 페이로드 계약 결과물이 아직 develop 에 없습니다 — 현재
  Core/WatchConnectivity/Sources 에는 WatchSessionCoordinator / WatchMessenger 두 파일뿐이고
  Codable 도메인 타입이 존재하지 않습니다. 여기서 계약을 새로 발명하면 그 이슈들과 충돌하므로,
  지금 존재하는 계약([String: Any] 딕셔너리 무변형 전달)만 고정해뒀습니다.
  페이로드 타입이 머지되면 CoreWatchConnectivityTests 에 라운드트립·하위호환 테스트를 이어 붙이면 됩니다.
• WatchMessenger 의 Swift 6 Sendable 경고(stored property 'coordinator' of 'Sendable'-conforming class ... has non-Sendable type)는 이 PR 이전부터 있던 것이라 손대지 않았습니다. 코디네이터의 격리
  모델(@MainActor 로 묶을지, 델리게이트 큐를 명시할지)을 정하는 건 페이로드 계약 이슈와 같이 봐야 합니다.
• CI 러너의 watchOS 시뮬레이터 런타임 유무는 실제 러너에서만 확인됩니다. 로컬은 watchOS 26.5 가
  설치돼 있어 통과했고, 러너에서 빠져 있으면 위 1번 스텝 경고 로그로 바로 드러납니다. 이 PR 의 CI 실행
  결과에서 확인해 주세요.
• sendMessage 가 ack(replyHandler)를 요구하게 된 만큼, 상대 앱 구현 시
  session(_:didReceiveMessage:replyHandler:) 로 응답해야 합니다. 응답하지 않으면 전달 실패로 에러가
  올라옵니다(정지하지는 않습니다).

📌 리뷰 포인트

• sendMessage 의 replyHandler 도입이 가장 중요한 판단 지점입니다. async throws 시그니처를
  유지하면서 영구 정지를 없애려면 ack 를 받는 수밖에 없다고 봤습니다. 워치 페이로드를 단방향 fire-and-forget
  으로 갈 계획이라면 여기서 시그니처 자체를 바꾸는 게 맞습니다 — 의견 주세요.
• WatchSessionProviding 이 과한 추상화인지. 구현체가 실제 WCSession + 테스트 대역 2개라 seam 자체는
  정당하다고 봤지만, 노출 범위(메서드 5개)가 더 줄어도 되는지 봐주세요.
• 활성화 가드(sessionNotActivated)를 updateApplicationContext 에도 넣은 것 — 기존에는 활성화 전 호출이
  ObjC 예외로 죽었으므로 동작 변화지만 개선 방향이라고 판단했습니다.
• CI 스텝을 별도 잡이 아니라 기존 잡에 이어 붙인 선택 (러너 시간 vs 잡 분리 가독성).
• AppProduct/ 는 한 줄도 건드리지 않았습니다 (절대 규칙 ✨ Feature: LoadingView 제작 #9).

✅ Checklist

PR이 다음 요구 사항을 충족하는지 확인해주세요!!!

• 커밋 메시지 컨벤션에 맞게 작성했습니다
  • 해당 링크 : 깃 모지 컨벤션
• 유지-보수를 위해 주석처리를 잘 작성하였는가?
  • 해당 링크 : Xcode 주석 정리

[JEONG-J]

develop 병합 시 재작성한 범위

#1212 리팩터로 코디네이터가 WatchMessage/WatchEnvelope 봉투 기반으로 다시 쓰였고
WatchMessenger 는 삭제됐습니다. 이 브랜치가 들고 온 seam·테스트는 옛 API 를 겨냥하고
있어 그대로는 컴파일되지 않아서, develop 구현을 정답으로 두고 아래처럼 재작성했습니다.

1. WatchSessionProviding 재설계

develop 코디네이터가 WCSession 에서 실제로 쓰는 표면이 늘어나서(큐·컨텍스트 시딩·활성화
상태) seam 도 그만큼 넓혔습니다.

• 추가: isActivated · receivedContext · outstandingTransfers · transfer(userInfo:)
• 추가: WatchUserInfoTransfer 프로토콜 (WCSessionUserInfoTransfer 준수) — 큐 만료 취소를
  검증하려면 전송 핸들도 대역이어야 합니다.
• 유지: 메서드 이름을 WCSession 원본과 다르게 두는 규칙(전달 익스텐션의 자기 재귀 방지)

코디네이터는 WCSession.default 직접 접근을 걷어내고 init(session:) 으로 주입받습니다.
기본값이 WCSession.default 라 기존 호출부(WatchSessionCoordinator())는 그대로 씁니다.

2. 델리게이트 로직을 테스트 가능한 지점으로 분리

WCSession 인스턴스를 테스트에서 만들 수 없어 델리게이트 콜백을 직접 호출할 수 없습니다.
콜백은 값만 뽑아 아래 내부 함수로 hop 하고, 테스트는 그 함수를 직접 구동합니다.

• applyActivation(_:reachable:seeded:) · applyReachability(_:) · applyReceivedContext(_:)
• ingest(userInfo:) · handle(request:reply:)

이 과정에서 이 브랜치가 담고 있던 개선 두 가지를 새 구현에 이식했습니다.

• .activated 라도 error 가 있으면 활성화로 보지 않는다 — 무시하면 화면은 「연결됨」인데
  모든 전송이 조용히 실패합니다.
• 활성화 전 도달성 변화는 무시한다 — 「도달 가능」인데 전송이 .sessionNotActivated 로
  죽는 상태를 만들지 않습니다.

3. 테스트 재작성

FakeWatchSession 은 넓어진 seam 에 맞춰 다시 썼고, WatchSessionCoordinatorTests 는 새 API
(requestSync() · requestAttendance(_:) · notifyAttendanceChanged(_:) ·
publishSessionState(_:) · enqueue(_:) · purgeExpiredQueue(now:) · setRequestHandler(_:) ·
receivedUserInfo())를 겨냥해 26개로 재작성했습니다.

• 활성화/도달성 전이, 콜드런치 컨텍스트 시딩과 덮어쓰기 금지
• requestSync 성공 · .remote · .unexpectedReply · .notReachable · .sessionNotActivated
• 전송 실패 분류 (WCError 코드 → 도메인 에러 / 그 외 → transportFailure 원본 보존)
• 큐 채널 규칙(.noticeRead 허용, 왕복형 3종은 .unsupportedChannel)
• purgeExpiredQueue(now:) 180분 경계 — 정확히 180분은 유효
• handle(request:) 의 「응답은 정확히 한 번」 계약: 미등록 · 손상 · 상위 스키마 · 정상 회신

삭제: WatchMessengerTests.swift — 검증 대상인 WatchMessenger 자체가 #1212 에서
삭제됐습니다. 그 파일이 지키던 계약(봉투 왕복 · 스키마 버전 상한)은 develop 의
WatchEnvelopeTests · WatchMessageTests 가 이미 덮고 있어 별도로 옮기지 않았습니다.

4. 그대로 반영한 것

.github/workflows/tuist-ci.yml watchOS 스텝 3종, UMCApp/Makefile 의 build-watch ·
WATCH_SCHEME · WATCH_DESTINATION, MAKEFILE_GUIDE.md 문서는 원안 그대로입니다.
Core/WatchConnectivity/Project.swift 의 includesTests: true 는 develop 에 이미 있어
중복 없이 병합됐습니다.

검증

항목	결과
make test SCHEME=CoreWatchConnectivity	69 tests / 5 suites 통과
make build-watch	BUILD SUCCEEDED
UMCWatchApp (watchOS Simulator) 테스트	91 tests / 11 suites 통과
make test (iOS)	43 tests / 8 suites 통과

후속 확인 부탁드립니다

CI 의 make build-watch 는 build 액션이라 UMCWatchAppTests 는 컴파일되지 않습니다
(위 91개는 로컬 실행 결과). 워치 테스트까지 CI 에서 잡으려면 build-for-testing 으로 바꾸거나
런타임이 설치된 러너에서 기종을 지정해야 하는데, 이 PR 범위 밖이라 그대로 뒀습니다.