iOS/WWDC

WWDC24 - Meet Swift Testing

suee97 2024. 8. 3. 23:48

https://developer.apple.com/videos/play/wwdc2024/10179/

 

Meet Swift Testing - WWDC24 - Videos - Apple Developer

Introducing Swift Testing: a new package for testing your code using Swift. Explore the building blocks of its powerful new API, discover...

developer.apple.com

 

* XCode16 부터 지원되는 기능입니다.

 

 

Building blocks

 

파일을 추가할 때 새로 생긴 템플릿이 생긴걸 볼 수 있습니다.

 

 

@Test attribute

함수가 테스트라는 것을 나타냅니다.

 

이걸 붙이면 XCode가 테스트인걸 알고 왼쪽에 실행 버튼을 만들어줍니다.

 

- 글로벌 함수가 될 수도, 타입의 메소드가 될 수도 있습니다.

- async나 throws를 붙일 수 있습니다.

- May be global actor-isolated (such as @MainActor) (잘 몰라서 번역 없이 그대로 가져왔습니다.)

 

 

#expect() macro

조건이 참인지 검사합니다.

 

#expect(조건) 방식으로 작성할 수 있습니다.

 

 

테스트에 실패한 경우 이렇게 조금 더 자세하게 결과를 확인할 수 있습니다.

 

 

영상에서 제공되는 예시입니다.

 

 

try #require() macro

조건이 false이면 테스트를 멈춥니다.

옵셔널 값을 해제할 때 사용할 수 있습니다.

 

테스트를 더 진행하는게 의미가 없을 수 있습니다. 그럴 때 require를 사용하면 좋을 것 같습니다.

 

 

Display name

 

test_태그아이템컨트롤러에서_태그가_어쩌구면_어쩌구인지...() {} 형식이 아니라 테스트에 display name을 넣어서 어떤 테스트인지 쉽게 확인할 수 있게 바뀌었습니다.

display name을 작성하면 test navigator에서도 이름이 바뀝니다. (원래는 그냥 함수명)

 

 

Trait

테스트에 정보를 제공합니다. 바로 위의 Display name이 그 중 하나입니다.

 

Built-in Traits 입니다. 몇몇은 진짜 쓸모가 있어 보입니다. 버그가 있으면 참고할만한 웹사이트를 제공할 수 있고, 태그를 설정하거나, 특정 환경에서만 테스트가 실행될 수 있도록 할 수도 있습니다.

 

 

@Suite attribute

테스트 묶음(?) 이라고 보시면 될 것 같습니다.

 

코드일부가 화살표에 가려져있는데 struct TagItemConverterTests입니다.

이렇게 suite를 명시할 수 있지만, struct 안에 @Test attribute가 들어가면 암묵적으로 저 sturct는 test suite입니다.

 

- 관련된 test, suite을 그룹화 할 수 있음

- @Suite로 명시할 수 있고, @Test를 포함한 타입은 암묵적으로 Suite임

- 프로퍼티를 가질 수 있음

- set up, tear down 로직에 활용되는 init deinit을 활용할 수 있음

- Initialized once per instance @Test method (정확히 이해는 안가지만, 테스트 하나당 하나의 suite을 가진다는 것 같습니다. 부정확한 정보일 가능성 매우 높음)

 

 

Common workflows

Tests with conditions

몇몇 테스트는 특정 환경에서만 실행되어야 합니다.

이럴 땐, condition trait을 적용할 수 있습니다.

 

조건이 false이면 테스트를 스킵합니다.

 

절대 실행을 원하지 않는 경우 disabled를 쓸 수 있습니다.

 

이런식으로 테스트는 작성하되 테스트는 실행하지 않고, disable한 이유를 적을 수 있습니다.

 

bug trait을 쓸 수도 있습니다.

 

 

특정 OS 버전에서만 테스트할 경우에는 이렇게 쓰면 됩니다.

 

 

Tests with common characteristics

 

태그로 테스트들을 그룹화할 수 있습니다.

 

 

이런 식으로 Suite 안에 Suite을 넣고 태그를 줄 수 있습니다.

이건 꽤나 유용해 보입니다. feature기준으로 태그를 나누면 특정 feature에 대한 테스트만 진행하는 것이 쉽습니다.

 

 

Tests with different arguments

이것도 꽤나 유용한 기능이 될 것 같습니다. 테스트를 할 때 같은 함수이더라도 nil일때, 데이터가 없을 때, 데이터가 예상보다 많을 때 등등 다양한 조건을 적용합니다. 그럴 때마다 이름만 다른 함수를 여러 개 작성했어야 했는데, 이 기능으로 중복을 줄일 수 있을 것 같습니다.

유니크한 함수 이름을 결정하는 것도 꽤 어려운 일인데, 이제는 문제가 없겠네요.

이 기능은 parameterized testing 이라고 합니다.

 

 

엄청 간단하게 작성했는데, 이런식으로 사용할 수 있습니다.

 

 

성공했을 때의 test navigator 입니다. 저렇게 어떤 인수들로 테스트가 진행되었는지 확인할 수 있습니다. 

 

 

실패한 케이스(파라미터)에 대해서 개별적으로 다시 테스트할 수 있습니다.

 

Run arguments in parallel. 병렬적으로 수행되어서 결과를 빠르게 볼 수 있습니다.

따라서, 테스트함수 내에서 for loop을 돌리면서 테스트를 돌리는 것보다 더 효율적입니다.

 

 

Swift Testing and XCTest

 

 

 

쭉 보면 될 것 같습니다 ,,

타입은 struct가 값타입이기 때문에 stuct를 쓰는 것이 더 괜찮다고 합니다.

 

XCUIApplication, XCTMetric 은 Swift Testing에서 제공되지 않으니 기존 XCTest를 써야 합니다.