XCTest 테스트가 잘 돌아가는데 새 프레임워크로 한꺼번에 옮길 이유가 있는지 망설여집니다.
결론: 새 순수 Swift 단위 테스트는 Swift Testing을 우선 적용하고, 기존 XCTest는 위험이 낮은 범위부터 나눠 옮기세요. UI 자동화 등 XCTest 기능에 기대는 테스트는 유지하고, 두 프레임워크를 함께 실행해 실패 처리부터 검증하는 편이 안전합니다.
이 글은 XCTest 단위 테스트를 유지하면서 마이그레이션 비용을 가늠하는 독립 개발자를 위한 기준입니다.
새 프레임워크의 실패 보고와 보조 함수 동작을 확인하려는 소규모 팀에도 적합합니다.
로컬이나 원격 Mac에서 Xcode 테스트와 CI를 반복 실행하는 프로젝트 유지 담당자도 참고할 수 있습니다.
[ SECTION_01 ] 테스트 범위: 순수 Swift 단위 테스트부터 옮깁니다
마이그레이션의 첫 기준은 파일 수가 아니라 테스트의 책임입니다. 외부 UI, 실제 기기 동작, 성능 측정에 기대지 않는 순수 Swift 로직 테스트부터 후보로 삼으세요. 입력과 출력이 명확하고 테스트 간 공유 상태가 적다면 새 프레임워크의 동작을 따로 검증하기도 쉽습니다.
반대로 테스트가 XCTest의 특정 기능이나 기존 보조 함수에 연결되어 있다면, 먼저 의존성을 기록하세요. 한 테스트 파일에 섞인 헬퍼 호출, 상속 구조, 설정과 해제 과정도 확인 대상입니다. 겉으로는 단순한 단위 테스트여도 실패 처리나 초기화 방식이 XCTest에 묶여 있을 수 있습니다.
Apple은 Swift Testing 문서에서 테스트 작성과 실행 기능을 안내합니다. 새 테스트에서 매크로 기반의 검증이나 매개변수화가 유용해 보이더라도, 기능 목록만으로 기존 테스트의 이전 가능성을 단정하지 마세요. 실제 테스트 하나를 전환하고, 결과 보고와 유지보수 방식이 팀에 맞는지 확인해야 합니다.
XCTest와 Swift Testing은 한 프로젝트에서 함께 쓸 수 있나요?
가능합니다. Apple의 XCTest 마이그레이션 문서는 두 프레임워크의 공존과 이전 시 고려사항을 설명합니다. 따라서 프로젝트 전체를 한 번에 바꾸기보다, 새 테스트는 Swift Testing으로 작성하고 기존 XCTest는 필요한 순서에 따라 남겨둘 수 있습니다.
다만 공존 가능성과 모든 조합이 검증되었다는 뜻은 다릅니다. 테스트 대상, 호출하는 보조 함수, 결과 수집 경로를 함께 확인하세요. 특히 한 프레임워크에서 다른 프레임워크의 단언 함수를 호출하는 경우에는 실패를 테스트 실행기가 올바르게 보고하는지 별도로 시험해야 합니다.
[ SECTION_02 ] 테스트 기능: XCTest를 유지할 경계를 먼저 정합니다
UI 자동화가 포함되어 있다면 XCTest를 성급히 제거하지 마세요. Apple의 XCUIAutomation 문서는 앱 UI를 대상으로 하는 자동화 기능을 다룹니다. 앱 실행, 화면 요소 조작, 사용자 흐름 확인이 테스트의 핵심이라면 기존 UI 테스트를 유지하는 쪽이 명확한 선택입니다.
성능 측정도 별도 경계로 다루세요. XCTest 성능 테스트 문서에 설명된 측정이 현재 프로젝트의 기준선이나 회귀 확인에 쓰인다면, 대체 경로를 실제로 확인하기 전까지 해당 테스트를 옮기지 않는 편이 안전합니다. Objective-C 예외 검증처럼 기존 XCTest 기능에 의존하는 경우도 같은 원칙을 적용하세요.
반면 테스트 데이터 조합이 많아 반복 코드가 늘어났다면 Swift Testing의 매개변수화 테스트가 현재 불편을 줄이는지 살펴볼 수 있습니다. 프로세스 종료 여부를 검증하는 테스트가 부족하다면 종료 테스트 기능도 후보입니다. 새 기능의 존재 자체가 이전 사유는 아닙니다. 현재 테스트가 놓치는 조건을 실제로 검증하는지 확인해야 합니다.
[ SECTION_03 ] 첫 번째 확인: 혼합 실행에서 실패 의미를 검증합니다
이전 전후의 테스트 결과가 같아 보여도 실패가 누락되거나 잘못 분류되면 마이그레이션은 완료된 것이 아닙니다. 다음 순서로 시험 테스트를 만드세요.
- 실패 기준선 기록: 기존 XCTest 단언이 실패했을 때 로컬 실행과 CI에서 어떤 테스트 이름과 오류가 표시되는지 저장합니다.
- Swift Testing 테스트 추가: 기존 단언 헬퍼를 새 테스트에서 호출하는 작은 사례를 만듭니다. 헬퍼를 직접 호출할 수 없다면, 동일한 오류 조건을 만들어 비교합니다.
- 의도적 실패 주입: 기대값을 일부러 어긋나게 해 실행 결과가 실패로 기록되는지 확인합니다. 오류 메시지와 테스트 식별도 기존 기준선과 비교합니다.
- 결과 수집 확인: 명령줄 실행과 Xcode 테스트 결과에서 실패가 같은 방식으로 나타나는지 확인합니다. CI가 새 테스트 결과를 누락 없이 모으는지도 살핍니다.
- 호환성 보고 유지: 상호 운용 관련 경고나 문제 보고를 끄는 것으로 검증을 대신하지 마세요. Apple의 마이그레이션 안내와 Swift Testing 개요를 확인하고, 경고가 생긴 호출 경로를 먼저 좁힙니다.
이 절차는 보조 함수 이름을 그대로 옮기는 것보다 중요합니다. 같은 함수가 호출되더라도 새 테스트 실행기에서 실패가 어떤 단위에 연결되는지는 결과로 확인해야 합니다. 실패를 재현할 수 없거나 결과가 일관되지 않으면 해당 헬퍼를 새 프레임워크에 맞춰 분리하고, 이전 테스트는 XCTest에 남겨두세요.
[ SECTION_04 ] 병렬 실행: 공유 상태와 격리 조건을 확인합니다
테스트가 순서에 따라 성공하거나 실패한다면 프레임워크 교체보다 격리 문제가 먼저입니다. 전역 변수, 공용 파일 경로, 같은 계정으로 접근하는 네트워크 리소스, 테스트 간 재사용되는 데이터가 대표적인 위험 요소입니다. 실행 순서를 고정했을 때만 통과하는 테스트도 별도로 표시하세요.
Apple의 병렬 테스트 안내는 병렬 실행과 관련한 테스트 동작을 설명합니다. 이를 근거로 모든 테스트가 자동으로 안전해진다고 판단할 수는 없습니다. 전환 후보마다 단독 실행과 전체 실행을 반복하고, 서로 다른 실행 순서에서도 결과가 유지되는지 기록하세요.
검증 자료는 성공 횟수만으로 충분하지 않습니다. 실패한 테스트 이름, 실행 설정, 공유 자원 사용 여부, 재현 절차를 남기세요. 같은 조건에서 결과가 반복되지 않으면 해당 테스트를 병렬 실행에서 분리하거나 공유 자원을 격리한 뒤 다시 평가해야 합니다. 성능 개선은 실제 프로젝트 측정 결과가 나오기 전까지 마이그레이션의 전제로 두지 마세요.
[ SECTION_05 ] 두 번째 확인: Swift Package Manager와 CI를 같은 기준으로 맞춥니다
Swift Package Manager 프로젝트도 새 프레임워크의 적용 가능성을 테스트 실행 환경에서 확인해야 합니다. Package.swift의 테스트 대상, 사용하는 Swift 도구 체인, 로컬 실행 명령, CI의 테스트 명령을 한곳에 기록하세요. 새 테스트가 개발자 컴퓨터에서만 검색되거나 실행되는 상태라면 팀 전체의 이전으로 간주하지 마세요.
도구 체인 지원 범위는 설치된 Xcode와 Swift 버전에 맞춰 확인해야 합니다. 특히 Xcode 27을 사용한다면 Xcode 27 릴리스 노트에서 해당 설치본의 변경사항을 확인하고, CI 이미지에도 같은 판단이 적용되는지 검토하세요. 릴리스 노트에 기재된 내용과 프로젝트에서 실제로 빌드·실행한 결과를 구분해서 기록해야 합니다.
명령줄에서 테스트를 실행하는 절차도 고정하세요. 빌드 성공만 확인하지 말고, 테스트 발견 여부와 실패 결과 수집, 저장된 결과 파일을 다시 확인하는 방식까지 포함합니다. 테스트 계획이나 CI 단계가 여러 개라면 새 테스트가 어느 단계에서 실행되는지 명시하세요. 한 번의 로컬 성공은 다른 환경에서의 재현성을 보장하지 않습니다.
[ SECTION_06 ] 의사결정표: 새 테스트 우선, 단계적 이전, 기존 유지
아래 표는 테스트 단위로 판단하는 기준입니다. 프로젝트 전체에 하나의 결론을 강요하지 말고, 테스트 유형과 실패 기록에 따라 서로 다른 경로를 선택하세요.
| 선택지 | 적합한 조건 | 확인할 근거 | 다음 조치 |
|---|---|---|---|
| 새 테스트에 Swift Testing 적용 | 순수 Swift 로직이며 의존성과 공유 상태가 적음 | 로컬·CI에서 테스트 발견과 실패 보고가 일치함 | 신규 테스트에 우선 사용 |
| XCTest에서 단계적 이전 | 기존 단위 테스트 중 의존성을 분리할 수 있음 | 헬퍼와 단언의 실패 의미를 혼합 실행으로 확인함 | 작은 묶음씩 옮기고 결과 비교 |
| XCTest 유지 | UI 자동화, 성능 측정, 특수한 기존 동작에 의존함 | 대체 기능이나 호환 경로를 프로젝트에서 검증하지 못함 | 기존 실행 경로를 보존하고 다시 평가 |
팀의 마이그레이션 기준은 “새 프레임워크로 바꿨는가”가 아니라 “테스트 목적이 유지되고 실패가 같은 수준으로 드러나는가”여야 합니다. Apple의 XCTest 문서와 Swift Testing 문서를 함께 확인하면서, 새 테스트와 이전 테스트의 책임 경계를 코드 리뷰에서 알아볼 수 있게 남기세요.
[ SECTION_07 ] 원격 Mac 검증은 환경 재현을 기준으로 판단합니다
원격 Mac을 테스트에 쓰려면 호스트 사양만 보지 말고 실제 프로젝트의 실행 경로를 재현하세요. Xcode 도구 체인, 저장소 체크아웃, 의존성 획득, 테스트 명령, 결과 파일 회수, 실패 재현까지 팀의 CI 흐름과 같은 순서로 확인해야 합니다. 원격 실행 결과가 달라진다면 프레임워크 차이라고 단정하지 말고 도구 체인과 설정 차이를 먼저 분리하세요.
이 글에서는 특정 원격 환경의 구성이나 테스트 기록을 확인할 수 있는 자료가 제공되지 않았으므로, 성능이나 지원 범위를 수치로 추정하지 않습니다. 임시 검증 환경이 필요하다면 맥 미니 대여 가격과 이용 조건을 먼저 살펴보고, 실제 테스트 명령과 결과 파일을 기준으로 적합성을 판단하세요.
기존 방식에 계속 머무르면 이미 익숙한 XCTest 보조 함수와 CI 흐름을 유지할 수 있지만, 새 테스트 기능을 별도로 평가하기 어렵고 오래된 실행 경로를 함께 관리해야 합니다. 반대로 Mac을 직접 구입하면 상시 접근이 편리하지만, 테스트 용도만으로 하드웨어를 확보하고 업데이트와 유지관리를 맡아야 합니다. 짧은 검증이나 지속 회귀 테스트를 위한 환경이 필요하고 구매 부담을 피하고 싶다면 NOVAKVM의 원격 Mac을 시험 경로로 검토할 수 있습니다. 다만 장기간 상시 부하가 이어지거나 물리 장치 연결이 필요한 프로젝트라면 직접 보유한 Mac이 더 적합할 수 있습니다. 임시 테스트 환경이나 반복 빌드용 Mac이 필요한 경우에는 NOVAKVM의 원격 Mac 이용 안내에서 접근 방식을 확인한 뒤, 프로젝트의 실제 테스트 결과로 최종 판단하세요.