WWDC24) Swift testing으로 테스트 심화하기

📘 Swift testing으로 테스트 심화하기 (Xcode 16 기준)

 

swift의 강력하고 표현력있는 기능을 위한 최신 오픈 소스 테스트 라이브러리

- 테스트는 개발 프로세스의 중요한 단계

- 코드가 사용자에게 전달되기 전에 문제를 발견하고 뛰어난 품질의 제품을 출시 할 수 있다는 자신감

- 계속 늘어나는 테스트 모음 관리의 어려움

 

 

- 코드가 복잡해질수록 테스트를 읽고 이해하기 쉽도록 만드는게 중요

- 코드에서 발생할 수 있는 모든 에지 케이스를 다루려면 많은 노력 필요

- 대규모 테스트 컬렉션을 구성하고 연관짓는 것은 복잡한 일이 될 수 있음

- 테스트 사이에 숨겨진 종속성 > 테스트 취약, 예기치 않은 오류 

 

1️⃣ Swift Testing 개요

• Swift Testing은 Xcode 16에 새롭게 도입된 공식 오픈소스 테스트 프레임워크.
• 기존 XCTest의 한계를 극복하고, 표현력 있고 유지보수가 쉬운 테스트 코드를 작성할 수 있게 지원. (Expressive code)
• Swift 언어 자체의 특성과 문법을 적극적으로 활용함.

 

2️⃣ 기대치(Expectation) 시스템 : 코드가 예상대로 작동하는지

true/false의 간단한 표현식

✅ 기본적인 기대치

• expect(value == true) 또는 expect(user.name).toEqual("Suvera") 등으로 코드의 의도를 명확히 표현.
• expect() 내부는 일반 Bool이 아니라 matcher 기반 DSL로 동작함.

 

 

✅ 오류 처리 기대치 – expect throws

오류처리 테스트는 사용자 경험에 중요. 잘못된 입력과 예상치못한 조건을 마주친 경우에도 코드가 깔끔하게 실패하도록

 

- 코드의 해피 패스를 테스트하고 throw 함수가 성공적으로 반환되기를 기대 -> 테스트 내부에서 호출

함수에서 오류 발생 시 테스트 실패

 

- 함수가 성공적으로 실행되고 값을 반환하면 기대치를 사용하여 예상과 맞는지 확인 가능 

 

- 반면, 실패 사례가 의도대로 작동하는지 확인하려면 함수가 발생시킨 오류를 catch하고 검사해야 함.

do-catch 구문 추가 방식 - 코드가 장황, 오류가 발생하지 않으면 잘 진행됐는지 알수 없음

 

expect 매크로 사용 : brew 함수가 오류를 발생시키면 이 테스트가 통과됨. 오류가 없으면 테스트 실패

 

 

• 오류를 throw할 것으로 기대되는 코드에 대한 테스트를 간결하게 작성.

import Testing

@Test func brewTeaError() throws {
    let teaLeaves = TeaLeaves(name: "EarlGrey", optimalBrewTime: 4)
    #expect(throws: (any Error).self) {
        try teaLeaves.brew(forMinutes: 200) // We don't want this to fail the test!
    }
}

• 특정 오류 타입 검증 : 모든 에러대신 해당 타입 전달

import Testing

@Test func brewTeaError() throws {
    let teaLeaves = TeaLeaves(name: "EarlGrey", optimalBrewTime: 4)
    #expect(throws: BrewingError.self) {
        try teaLeaves.brew(forMinutes: 200) // We don't want this to fail the test!
    }
}

• 커스텀 검증도 가능: 오류 유효성 검사를 맞춤화해 특정 타입이나 오류 사례 연결된 값 또는 속성이 올바른지 여부
• 또는 코드에서 발생한 오류가 작업에 맞는 오류인지 확인하는 등 

import Testing

@Test func brewTeaError() throws {
    let teaLeaves = TeaLeaves(name: "EarlGrey", optimalBrewTime: 4)
    #expect(throws: BrewingError.oversteeped) {
        try teaLeaves.brew(forMinutes: 200) // We don't want this to fail the test!
    }
}

import Testing

@Test func brewTea() {
    let teaLeaves = TeaLeaves(name: "EarlGrey", optimalBrewTime: 4)
    #expect {
        try teaLeaves.brew(forMinutes: 3)
    } throws: { error in
        guard let error = error as? BrewingError,
              case let .needsMoreTime(optimalBrewTime) = error else {
            return false
        }
        return optimalBrewTime == 4
    }
}

 

 

3️⃣ 필수 기대치 – require

• 옵셔널 값이 nil이면 조기에 테스트를 종료시킴.
• 예: guard let 같은 논리를 require로 테스트에 적용 가능.

import Testing

@Test func brewAllGreenTeas() {
  #expect(throws: BrewingError.self) {
    brewMultipleTeas(teaLeaves: ["Sencha", "EarlGrey", "Jasmine"], time: 2)
  }
}

 

->  발생하는 기대값을 포함한 모든 일반 기대값을 필수 기대값으로 만들 수 있다. 

import Testing

@Test func brewAllGreenTeas() throws {
  try #require(throws: BrewingError.self) {
    brewMultipleTeas(teaLeaves: ["Sencha", "EarlGrey", "Jasmine"], time: 2)
  }
}

 

 

- 옵셔널 값의 유효성을 검사하는 경우

 

-> 필수 기대값을 사용하여 제어 흐름을 문서화 할 수 있다.

-> 마지막에 nil이 된 값을 검사하는 것은 의미가 없으므로  필수 기대값을 추가하면 테스트가 더 이상 할일이 없는 경우 조기에 종료

 

 

 

4️⃣ 실패를 허용하는 테스트 – withKnownIssue

• 테스트에서 알려진 오류를 문서화하기 위해 사용. 
• 테스트 실패 분류는 시간이 많이 걸림 > 즉시 수정 불가, 통제할 수 없는 요인.. 노이즈 추가되어 실제 문제를 알아차리지 못함.
• 외부 요인으로 인해 일시적으로 실패할 수 있는 테스트를 예상된 실패로 처리.
• 이 오류는 테스트 보고서에서 ‘예상된 실패(expected failure)’로 기록됨 → 실제 버그와 구분 가능.
• 이 기능은 CI/CD에서 신뢰할 수 있는 피드백 루프를 유지할 때 매우 유용.

아이스크림 기계가 아이스크림 콘을 만들 수 있는지 확인 > 기계가 작동하지 않아 실패

 

테스트를 비활성화할 경우 .disabled를 생각할 수 있는데

 

 

withKnownIssue 추천 : 테스트가 계속 실행되고 컴파일 오류에 대한 알림을 받음

-> 함수가 오류를 반환하면 예상했던 오류이기 때문에 테스트 결과가 테스트 실패에 포함되지 않음 !!

-> 대신 결과에서 예상했던 실패로 표시됨.

-> 문제 해결 되어 더 이상 오류가 발생하지 않으면 > 알림 

 

해당 호출을 제거하고 테스트를 다시 정상적으로 실행 가능

 

 

- 테스트에서 여러 확인 수행 

실패한 경우를 withKnownIssue로 래핑 > 나머지 유효성 검사가 실행되도록 할 수 있음.

 

- Custom test descriptions : 테스트 내부에서 일어나는 일을 한눈에 파악 , 문제가 발생했을 때 해결 방법을 안내할 수 있다.

간단한 열거형으로 작업 > 기본 설명은 일반적으로 간단

구조체, 클래스 같이 더 복잡한 타입 > 더 많은 노이즈 생성, 기본적으로 해당 타입의 설명에 테스트 중에는 쓸모없는 추가 데이터가 있기 떄문'

 

정보 표시 > 한 값을 다른 값과 구분하는 부분으 ㄹ찾기 힘듬. 프로덕션 코드에 영향을 주지 않으면서 각각에 간결한 테스트 설명을 제공

 

CustomTestStringConvertible 프로토콜 채택 > 맞춤형 테스트 설명 제공

 

테스트 보고서의 가독성 증가

 

5️⃣ 매개변수화된 테스트 – Parameterized Tests

- 에지 케이스를 포착하기 위해 다양한 조건에서 테스트 실행하는 건 좋지만 시간이 많이 걸림

- 가능한 모든 변수에 대해 별도의 테스트를 작성하는 것은 유지관리 힘듬 > swift testing > 다양한 인수로 단일 테스트 함수 쉽게 실행

 

✅ 목적

• 반복적인 테스트 코드를 제거하고, 하나의 테스트 함수로 다양한 입력을 처리할 수 있게 함.

여러 맛의 아이스크림 중 특정 맛에 견과류가 포함됐는지 확인. containNuts 속성은 열거의 모든 케이스에 대한 테스트 커버리지 필요.

바닐라 단일

 

 

 

매개변수화된 테스트

 

- 테스트 케이스는 서로 완전히 독립적, 병렬로 실행 가능 

- 모든 테스트 케이스를 테스트하는데 필요한 시간이 for루프나 별도의 테스트 함수를 사용할 때보다 줄어듭니다.

 

 

 

- xcode는 입력 유형이 Codable을 채택하는 경우 테스트 함수의 개별 테스트 케이스 재실행을 지원.

- 이를 통해 성공적으로 실행된 다른 테스트 케이스를 다시 실행할 필요없이 실패한 테스트 케이스만을 재시도

 

✅ 단일 인수 예시

• 각 인수는 테스트 내비게이터에서 별도의 실행 단위로 분리, 병렬 실행 가능.

 

이 테스트 함수가 배열의 값 중 하나에 대해 실패하면 실행이 중단되고 후속 인수를 테스트 하지 않음. 어떤 값이 실패 했는지 불분명

입력을 위로 이동 시켜 테스트 속성으로 전달할 수 있음. 매개변수화를 위해 컬렉션을 test 속성으로 전달하면, 테스트 라이브러리는 컬렉션의 각 요소를 한번에 하나씩 테스트 함수에 전달

 

하나가 실패하면 어떤 입력에 주의가 필요한지 명확하게 표시

 

두번째 함수 추가

 

열거형 외에도 모든 sendable 컬렉션을 테스트 속성에 전달 가능

 

 

✅ 다중 인수 예시

• zip을 활용해 모든 조합이 아니라 1:1 매핑만 테스트할 수 있음.

첫 번째 인수 뒤에 다른 인수 추가 , 두번째 컬렉션의 모든 요소는 두번째 인수로 전달, 이 두 컬렉션의 모든 요소 조합이 자동으로 테스트 됨.

 

인수가 두개인 테스트 함수는 가능한 모든 조합을 테스트 함

 

더 많은 입력을 추가하면 테스트 케이스의 수는 기하급수적으로 증가

 

=> 이러한 증가를 제어하기 위해 테스트함수는 최대 두개의 컬렉션을 허용 

=> Swift 표준 라이브러리의 zip 함수를 사용하여 함께 사용해야하는 입력 쌍을 짝지을 수도 있다

 

zip 을 호출하면 쌍으로 연결됨.

 

- zip은 튜플의 시퀀스를 생성

 

1번째 컬렉션의 각 요소를 두번째 컬렉션의 요소와 순서대로 쌍으로 묶는 방식

 

 

---

6️⃣ 테스트 정리 전략: 모음과 태그

✅ 테스트 모음(Collection)

• 테스트를 논리적 그룹으로 구조화할 수 있게 함.
• 하위 모음을 포함해 트리 구조 형성 가능.

suite에 다른 suite 포함 가능 : 테스트를 더욱 유연하게 구성할 수 있음

 

 

- 따듯한 디저트, 찬 디저트 

- add sub suites -> 테스트 그룹 사이의 관계를 더 명확하게 만들 수 있다.

 

✅ 태그(Tag)

• 파일/모음에 관계없이 테스트 간 논리적 연결을 위한 도구.
• 예: caffeinated, chocolatey, spicy, experimental
• 태그 기반으로 테스트 실행, 필터링, 그룹화, 테스트 계획 구성 가능

 

• 복잡한 패키지나 프로젝트에는 수백 ~ 수천개의 테스트와 모음이 포함 될 수 있음
• 일부 테스트의 하위 세트는 공통된 특성을 공유 할 수 있음

일부 테스트는 카페인이 함유된 음식과 관련, 일부는 초콜릿이 든 음식과 관련 -> 이 경우 태그로 두 세트에서 테스트를 연결

- 유의할 점 : 태그는 테스트 모음을 대체할 수 없다. 

- 모음은 소스 수준에서 테스트 함수에 구조를 부여하지만 태그는 공통점을 공유하는 서로 다른 파일, 모음, 대상의 테스트를 연결할 수 있도록 함. 

 

 

태그 선언 방법 

 

- 모든 음료에 카페인이 들어있고, 에스프레소 브라우니도 마찬가지

-> caffeinated 태그를 만들어 테스트가 별도의 모음에 존재해도 서로 연관시킬 수 있음

 

extension에 정적 변수 선언, 변수는 tag의 인스턴스여야 함

 

- 비밀 재료 -> tag 속성을 변수에 추가해 테스트에서 태그로 사용할 수 있도록 

 

태그는 drinkTests의 모음 수준에서 추가할 수 있음. 이 테스트에 사용된 모든 음료는 카페인이 들어있고 테스튼느 해당 모음에서 태그를 상속. -> expressoBrownieTexture에 추가 , DessertTests에 있는 유일한 카페인이 든 식품이므로 전체 DessertTests 모음에 추가하고 싶지 않을 것.

 

- 태그가 여러개 있을 수 있다. 

- 모카와 에스프레소 브라우니는 모두 카페인이 있지만 재료가 초콜릿임

 

-> 테스트 내비게이터가 테스트를 태그별로 그룹화하여 특정 태그가 있는 테스트를 실행할 수 있게 함

 

 

- 내비게이터는 기본적으로 소스 코드에서 해당 위치에 따라 정리된 테스트를 표시

- 테스트 내비게이터 하단의 필터 필드를 사용해 핫소스 관련 테스트 찾기

 

- xcode의 태그 제안

- seasonal, spicy, street food와 같은 태그 제안 표시 

 

- 기본적으로 필터 필드는 테스트의 표시, 함수 이름과 일치

- 진저브레드 쿠키의 스파이스 조합과 시금치와 아티초크 딥소스 비율 등의 테스트가 표시 

 

 

- 이름에 강조 표시된 단어가 없는 테스트를 제안 -> 일치하는 태그가 있기 때문

- 제안 팝업에서 spicy 클릭 > 입력한 내용을 테스트 내비게이터가 태그 필터로 변환 > 해당 태그가 없는 모든 테스트를 제거

 

 

그룹화된 태그들

 

 

 

 

7️⃣ 테스트 계획(Test Plan)

• 신뢰할 수 있는 핵심 테스트 세트가 있는 테스트 계획 만들기 가능
• 변경 시 발생할 수 있는 버그를 빠르게 포착

• Include Tags, Exclude Tags 기능 제공.
• 예: @seasonal, @unreleased 태그를 제외한 핵심 테스트만 실행.
• Xcode 내에서 태그별 실행 및 보고서 분석 가능.
• UI에서 태그 기반 테스트 실행 → 특정 기능이나 시기별 테스트 구성 가능.

단위테스트 대상 확장 > 모든 테스트 확인

 

- 테스트 계획 업데이트 : 모든 핵심 테스트 실행, sesonal 태그가 잇는 테스트 제외 

 

두개 이상의 태그

 

- 테스트 보고서

인사이트 화면 ㅣ 테스트 실패의 패턴을 보여주는 섹션

 

- spicy 태그 관련 모든 테스트가 실패 

 

xcode cloud도 swift testing을 지원하도록 업데이트 됨

 

app store connect > xcode cloud 탭에서 볼수 있음

 

 

 

 

 

8️⃣ 병렬 실행 & 직렬화 제어

✅ 병렬 테스트

• Swift Testing은 기본적으로 병렬 실행을 지원. 
• 모든 물리적 기기에서 병렬 테스트 실행 할 수 있음
• 동기/비동기 여부 관계없이 병렬로 처리됨.
• 테스트 실행 순서를 랜덤화(shuffled) 하여 테스트 간 숨겨진 의존성 감지 가능.

 

장점 > 실행 시간 단축

 

- XCTest와 큰 차이점 : 여러 프로세스를 사용하는 병렬화만 지원하여, 한번에 하나의 테스트만 실행하는 것과는 다름

- 테스트 함수를 MainActor같은 글로벌 액터에 격리 가능

실행 순서 랜덤화

 

이 테스트가 항상 순서대로 차례를 지켜 실행되면 두번째 테스트를 위한 컵케이크가 늘 준비되어 있음

테스트가 병렬로 실행되면 첫번째에 대한 두 번째의 종속성이 런타임에 노출되어 수정할 수 있음

 

- 이전 테스트 코드를 변환하는 경우, 이러한 종속성 중 일부가 이미 베이크 되어 있을 수 있다. 

- 스위프트 6은 기존 코드를 다시 작성할 때 일부 문제 발견에 도움이 될 수 있지만 다른 문제는 찾기 힘듬

- 첫 번째 단계로 코드를 swift testing으로 변환하고 문제는 나중에 해결하고 싶을수도 

 

 

✅ 직렬 실행 제어

 

• @serialized 모음 또는 테스트 함수에 적용 → 테스트를 순서대로 실행.
• 하위 모음에도 적용됨 (자동 상속됨).

테스트를 직렬로 실행해야됨.

 

-> 가능하다면 먼저 테스트 코드를 병렬로 실행하도록 리팩토링 하는 것을 고려 !

- .serialized는 매개변수화된 테스트 함수에 적용되어 테스트 케이스가 한번에 하나씩 실행되도록 할 수도 있음

 

직렬로 실행

 

- 그러나 스위프트는 이런 직렬화된 테스트와 관련 없는 다른 테스트는 병렬으로 실행 가능

 

- 병렬 테스트 기본 : 빠르게 실행 

- 병렬로 리팩토링 고려 

 

9️⃣ 비동기 테스트와 콜백

 

동시 실행 테스트 코드 작성 시 swift에서도 프로덕션 코드에서와 같이 동일한 동시 실행 기능 사용

✅ async/await 지원

• Swift의 async/await 그대로 사용 가능.
• Swift Testing은 Task 내부에서도 자연스럽게 작동함.
• 작업이 종료되는 동안 다른 테스트 코드가 cpu를 계속 사용할 수 있게 테스트를 일시 중단

✅ 완료 핸들러 → continuation 변환

• completionHandler 기반 코드도 async로 쉽게 래핑 가능.
• c, obj-c: 완료 핸들러로 비동기 작업의 끝을 알림 

테스트 함수가 반환된 후 실행되므로 함수가 성공햇는지 확인 ㅂ루가

스위프트는 대부분의 완료 핸들러에 대해 대신 사용할 수 있는 비동기 오버로드를 자동으로 제공

테스트 중인 코드가 완료 핸들러를 사용하는데 비동기 오버로드를 사용할 수 없다면 -> withCheckedContinuation 또는 withCheckedThrowingContinuation으로 기다릴 수 있는 표현식으로 변환

✅ 이벤트 확인 – confirmation

• 이벤트가 몇 번 호출되는지 확인 가능 (confirmation(count:))
• 기본값은 1회, 0 설정 시 호출되지 않아야 하는 상황 검증 가능.

또 다른 콜백은 두번 이상 실행 될 수 있는 이벤트 핸들러

- 전체 식시가 ㄷ끝날때마다 콜백 호출이 아니라 각 쿠키마다 한번 씩 호출

- 변수를 사용해 먹은 쿠키의 수를 계산하려고 하면  스위프트 6의 동시 실행 오류가 발생 

- 이렇게 변수를 설정하는게 안전하지 않기 때문에 

 

- 테스트 중인 코드가 콜백을 두 번 이상 호출할 수 있고, 호출 횟수를 테스트해야하는 경우 confirmation 사용.

- 다른 에상 횟수를 지정할 수도 있다.

 

 

 

🔟 테스트 인사이트 및 태그 기반 분석

• 테스트 리포트에 태그 정보가 함께 표시됨.
• 실패 패턴 → 공통 태그 기반 분석 가능 (spicy 태그 테스트가 전부 실패함 등).
• UI상에서 태그별 실행 버튼 및 실패 필터 제공 → 빠른 디버깅 가능.

---

🧠 Swift Testing의 장점 요약

	XCTest	Swift Testing
표현력	제한적	풍부한 DSL 기반
오류 테스트	복잡함 (do-catch)	expect throws 한 줄 처리
매개변수 테스트	없음	@Test(arguments:) 지원
태그/메타데이터	불가능	태그 및 정리 가능
병렬 실행	제한적	기본 병렬, 직렬화 제어 가능
비동기 지원	지원	await 및 continuation 완전 통합
유지보수	불편함	구조화된 관리 전략

 

---

📌 결론

Swift Testing은 테스트를 작성하는 것 이상의 경험을 제공합니다.
테스트를 구조화하고 병렬화하며, 태그와 기대치를 통해 정교한 커버리지와 품질 관리를 가능하게 해줍니다.
XCTest를 넘어, Swift다운 테스트를 위한 전환점입니다.