Swift Testing으로 SwiftUI 프로젝트를 어떻게 테스트할까? 2026 Xcode 27 초보자 튜토리얼

첫 테스트를 시작하기 전에 검증할 일을 고릅니다

점수판이 화면에 제대로 보이더라도, 점수를 더하는 계산이 틀리면 앱의 핵심 동작은 잘못된 것입니다. 화면을 먼저 검사하기보다 입력을 넣었을 때 결과가 맞는지 확인할 수 있는 로직을 고르세요. 이것이 이 글에서 다룰 Swift Testing SwiftUI 프로젝트 테스트의 출발점입니다.

테스트할 기능은 수업 프로젝트 안에서 작고 결과가 뚜렷한 것으로 고릅니다. 점수 더하기, 입력값 검사, 버튼을 눌렀을 때 상태가 바뀌는 기능이 적당합니다. 화면의 body 안에서 계산까지 처리하고 있다면, 해당 계산을 별도 함수나 타입으로 옮겨 화면 밖에서도 호출할 수 있게 정리합니다.

테스트를 과제 채점에 비유하면 이해하기 쉽습니다. 테스트 대상은 채점할 과제 부분이고, 단위 테스트는 한 가지 기능을 떼어 점검하는 방식입니다. 단언은 “이 입력이라면 이 결과여야 한다”는 채점 기준입니다. 경계 상황은 정상적인 입력의 끝부분이나 예상치 못한 값처럼 따로 확인해야 하는 경우를 뜻합니다.

Xcode 27에서 테스트 파일이 속한 곳을 확인합니다

테스트 대상은 앱 코드와 테스트 코드를 분리해 두는 프로젝트 영역입니다. 새 프로젝트에는 설정에 따라 테스트 대상이 함께 만들어질 수 있지만, 기존 프로젝트에서는 테스트 대상이 있는지 먼저 살펴야 합니다. Apple은 Xcode 프로젝트에 테스트를 추가하는 방법과 프로젝트에 새 대상을 설정하는 절차를 안내합니다.

Swift Testing으로 첫 테스트를 시작하기 전에 아래 순서로 준비하세요. 메뉴의 이름이나 배치는 설치한 버전에 따라 다를 수 있으므로, 정확한 항목은 프로젝트 설정 화면과 공식 문서를 함께 확인합니다.

1. 프로젝트 탐색기에서 앱 코드와 테스트 코드가 나뉘어 있는지 살펴봅니다.
2. 테스트용 파일이 있다면 파일을 선택해 어느 대상에 포함되는지 확인합니다.
3. 기존 프로젝트에 테스트 대상이 없다면 프로젝트 설정에서 테스트 대상을 추가합니다.
4. 테스트 파일에서 Testing을 가져오도록 준비합니다.
5. Xcode의 현재 버전과 운영체제 호환 여부를 공식 시스템 요구 사항에서 확인합니다.

테스트 코드를 앱 대상에만 넣으면 앱은 잘 실행되어도 테스트 실행 목록에서 찾지 못할 수 있습니다. 반대로 테스트 파일이 올바른 테스트 대상에 들어 있고 Testing을 가져오면, 프레임워크가 테스트를 인식할 조건을 갖추게 됩니다. Swift Testing이 제공하는 테스트 작성 방식은 Apple의 프레임워크 안내에서 확인할 수 있습니다.

작은 점수 계산으로 첫 테스트를 작성합니다

다음 예시는 양수만 점수에 더하도록 만든 간단한 타입입니다. 첫 함수는 정상 입력을, 두 번째 함수는 경계 상황에 가까운 입력을 확인합니다. 점수 계산을 테스트하는 예시는 Apple의 Swift Testing 학습 자료에서도 살펴볼 수 있습니다.

import Testing

struct ScoreCounter {
    private(set) var score = 0

    mutating func add(_ points: Int) {
        guard points > 0 else { return }
        score += points
    }
}

@Test
func addingPointsUpdatesScore() {
    var counter = ScoreCounter()
    counter.add(2)

    #expect(counter.score == 2)
}

@Test
func zeroPointsDoNotChangeScore() {
    var counter = ScoreCounter()
    counter.add(0)

    #expect(counter.score == 0)
}

코드를 읽을 때는 준비, 실행, 확인 순서로 봅니다. 먼저 검사할 상태를 준비하고, 함수에 입력을 전달한 다음, #expect로 예상 결과와 실제 결과를 비교합니다. 여기서 2와 0은 예시 입력입니다. 실제 프로젝트에서는 과제의 규칙에 맞게 바꾸세요.

Swift Testing의 예상 조건 문서는 #expect를 포함한 결과 확인 방법을 설명합니다. 학습 초기에는 한 테스트에 여러 기능을 몰아넣지 않는 편이 좋습니다. 입력 하나와 결과 하나를 연결하면 실패했을 때 어느 규칙을 다시 봐야 하는지 분명해집니다.

테스트 목록에 나오지 않을 때는 대상을 점검합니다

화면은 실행되는데 테스트 목록에 함수가 나타나지 않는다면, 캐시를 지우거나 도구를 다시 설치하기보다 테스트 코드의 위치와 선언을 먼저 살펴보세요.

• 테스트 파일이 앱 대상이 아니라 테스트 대상에 포함되어 있는지 확인합니다.
• 파일에서 Testing을 가져왔는지 확인합니다.
• 테스트 함수가 @Test로 선언되어 있는지 확인합니다.
• 실행 결과 창에서 테스트 대상이 실제로 선택되었는지 확인합니다.

테스트는 보이지만 실패한다면 실행 문제와 코드 문제를 분리합니다. 같은 입력을 테스트 함수와 앱에서 사용했는지 살펴보고, #expect 안의 예상 결과가 과제 규칙에 맞는지 확인하세요. 입력도 기대값도 맞는데 실패한다면, 그때 실제 계산 로직을 다시 읽습니다.

실행 결과와 화면 확인은 따로 마무리합니다

테스트를 실행한 뒤에는 Apple의 테스트 실행 및 결과 해석 안내를 참고해 성공 또는 실패 상태와 상세 메시지를 살펴보세요. 성공은 해당 테스트가 설정한 조건을 통과했다는 뜻이지, 앱 전체가 완성되었다는 뜻은 아닙니다.

마무리할 때는 정상 입력뿐 아니라 의미 있는 경계 상황도 테스트에 넣고, 앱을 별도로 실행해 버튼과 화면 반응을 확인합니다. 시뮬레이터에서 실행된 것과 실제 기기 또는 수업에서 지정한 검수를 통과한 것은 서로 다른 결과입니다. 제출 전에는 과제 안내에 적힌 확인 범위를 기준으로 필요한 점검을 마치세요.

테스트를 저장하고 반복 실행할 환경이 필요한 경우에는 NodeMini의 맥 미니 이용 안내에서 이용 방식을 확인할 수 있습니다. 아직 맥이 없다면 NodeMini 안내 페이지를 참고해 현재 학습 환경에 맞는 선택지를 살펴보세요.

윈도우에서는 Xcode를 네이티브로 실행할 수 없고, 가상 환경은 설정과 호환성 확인이 추가로 필요합니다. 반면 맥을 직접 구매하면 초기 지출이 들고, 수업 기간에만 쓸 때는 사용하지 않는 기간에도 기기를 보유하게 됩니다. 단기간 과제나 환경 확인이 목적이라면 NodeMini의 원격 맥 대여로 실제 맥 환경을 이용하는 방법도 비교해 볼 수 있습니다. 다만 장기간 꾸준히 사용하거나 물리 기기 연결이 필수라면 직접 보유한 맥이 더 적합할 수 있습니다.