[XCTest] XCTest에 대해서 알아보기 1편

XCTest에 대해서 알아보기 1편

 

 

XCTest를 공식문서를 통해 정리

Nimble이랑 Quick도 어느순간부터 관성적으로 사용하고 있는데 이것들도 한번 같이 학습해보자.

사이드 프로젝트에서 테스트코드 작성하면서 점차 더 다양한 시나리오, 동작 플로우, 알고리즘 등에 대해서 더 세분화해서 테스트를 진행하는데 전에 정리 통한 복기가 필요하다고 느낌.

기존에도 유닛테스트는 자주 사용하고 있어서 익숙한데, UITest는 거의 사용하지 않고 있음.

스냅샷테스트 등이 있다고는 들었는데, 이렇게 사용하기 보다, Record 통해서 QA나 기획에서 이런 동작에 문제 없는지 확인 요청 왔을 때 코드 변경 후 테스트 위해서 사용 종종함.

 

서비스 개발에서 퍼포먼스 테스트는 해본 적은 없는데, 종종 깃허브 돌아다니면서 관련해서 처리하는 것들이 있어서 관심이 가다가도, 우선순위가 자꾸 낮아지게 되는 경향이 있음.

 

 

 

(공식문서)

https://developer.apple.com/documentation/xctest/defining_test_cases_and_test_methods

Apple Developer Documentation

 

테스트 대상에 테스트 사례 및 테스트 방법을 추가하여 코드가 예상대로 작동하는지 확인합니다.

 

 

 

 

공식문서의 Topics를 보면 XCTestCase와 XCTest로 나뉘는데, XCTest부터 알아보자.

XCTest

 

 

프로퍼티들도 있지만 자주 보이는 Setting Up and Tearing Down 위주로 알아보자.

 

Setting Up and Tearing Down

 

• setUp(completion: (Error?) -> Void)
  • 테스트 케이스 내에서 각각의 테스트가 불리기 전에 상태를 비동기적으로 리셋하고, 오류를 던질 수 있게끔 제공
• setUpWithError()
  • 테스트 케이스 내에서 각각의 테스트가 불리기 전에 리셋하고, 오류를 던질 수 있게끔 제공
• setUp()
  • 테스트 케이스 내에서 각각의 상태 리셋 제공
• tearDown(completion: (Error?) -> Void)
  • 각각의 테스트 케이스 종료 후에 클린업 비동기적으로 수행하고 오류 던지게끔 제공
• tearDownWithError()
  • 각각의 테스트 케이스 종료 후에 클린업 수행하고 오류 던지게끔 제공
• tearDown()
  • 각각의 테스트 케이스 종료 후 클린업 수행

 

간단히 말해서 setUp은 테스트가 수행되기 전 오직 1번, tearDown은 각각의 테스트가 종료된 후에 오직 1번 호출되는 메소드들

 

 

 

다음은 XCTestCase에 대해서 알아보자.

XCTestCase는 XCTest를 상속받고 있다.

 

OverView를 요약하자면 test의 method와 관련된 것들이 들어있으며, 퍼포먼스 테스트 등을 진행할 수 있다.

 

Managing Test Case Execution

• runsForEachTargetApplicationUIConfiguration: Bool
  • 앱에서 설정가능한 조합에 대해 UI테스트를 실행할지 여부, 기본값은 false이다.
  • 해당 옵션 사용해 본 경험은 없어서 어떤 상황에 유용한지는 모르겠다.
  • Appearance(ex. 다크모드 라이트모드), Orientation(ex. 가로 세로), Localization(ex. en_US, zh_CN) 등
  • 테스트 시스템은 지원되는 설정의 가능한 모든 조합을 포함하는 구성 집합을 계산하고 XCUIApplication launch()를 호출하면 테스트 반복에 각 구성을 제공한다고 한다.
  • 예상으로는 UITest에서 설정 옵션에 대해서 테스트 하는 것으로 보임.
• continueAfterFailure: Bool
  • 실패가 발생한 후에도 계속 진행할 지 말지를 결정하는 메소드 true경우 계속 진행.
• excutionTimeAllowance: TimeInterval
  • 시간 초과 오류로 인해 테스트가 실패하기 전 가장 가까운 minute로 반올림 된 시간(second)
  • 테스트 시간이 이 값을 초과하면 실패로 기록함. 기본값은 600초(10분)으로 이 속성을 이용하여 장기간 실행을 방지함.

 

 

Creating Asynchronous Test Expectations

비동기 테스트에서 주로 사용

 

• func expectation(description: String) -> XCTestExpectation
  • 새로운 expectation을 만듭니다. parameter를 넣어주면 실패 시 해당 설명이 로그로 나타남.

 

해당 비동기 작업이 성공이라면 fulfill을 호출하여 비동기 작업이 완료되었음을 알려서 테스트의 결과를 확정지어야 함.

 

 

Waiting for Expectations

비동기 테스트가 fulfill할 때까지 기다린다.

• func wait(for: [XCTestExpectation], timeout: TimeInterval)
  • 테스트가 지정된 시간 내에 기대치를 충족할 때까지 기다립니다.

 

 

테스트 코드 예시

func test_signIn() throws {
        let email = "mock1024@gmail.com"
        let password = "12a4!g"
        
        let expectation = XCTestExpectation()
        expectation.expectedFulfillmentCount = 1

        apiClient?.signIn(email: email, password: password) { result in
            switch result {
            case .success:
                XCTAssert(true)
            case .failure(let error):
                if let error = error as? APIClient.APIError {
                    XCTFail(error.localizedDescription)
                } else {
                    XCTFail(error.localizedDescription)
                }
            }
            expectation.fulfill()
        }

        wait(for: [expectation], timeout: 30)
    }

 

expectedFulfillmentCount: 해당 이벤트가 한번만 발생해야 한다는 의미, 만약 2번 발생하면 fail

 

 

 

(참고)

https://blog.banksalad.com/tech/test-in-banksalad-ios-1/

뱅크샐러드 iOS팀이 숨쉬듯이 테스트코드 짜는 방식 1편 - 통합 UI테스트 | 뱅크샐러드