Testing with RxTest

[simoniful]

Ch.16 Testing with RxTest

👏🏻💯🚀
☝🏻 이 장을 놓치지 마라. 연구 결과에 따르면 개발자가 테스트 작성을 건너뛰는 이유는 두 가지다.

1. 버그가 없는 코드를 쓴다.
2. 테스트 작성은 재미없다.

첫 번째 이유가 당신에게 해당된다면 바로 고용될 것!
두 번째 이유에 동의하면 RxTest를 보자!

책을 읽기 시작하고 App 프로젝트에서 RxSwift를 사용하고 시작한 거 자체로, RxTest와 RxBlocking를 통해 RxSwift 코드에 대한 테스트도 작성할 수 있어야 한다. 자체로 테스트 작성을 쉽고 재미있게 만드는 우아한 API를 제공한다.

이번 챕터에서는 RxTest 및 RxBlocking에 대해 알아볼 거다. iOS 앱 프로젝트에서 여러 RxSwift 연산자와 생산 RxSwift 코드를 대상으로 테스트를 작성하는 예제를 포함해서 말이다.

Getting started

이번 챕터의 시작 프로젝트 이름은 Testing이며, 입력한 hex 색상 코드에 대해서 가능한, RGB값과 색상 이름을 제공하는 편리한 App이 포함되어 있다. Pod 설치를 실행한 후 프로젝트 workspace을 열고 실행해보자. 앱이 rayWenderrich Green으로 시작하는 것을 볼 수 있지만, 임의의 hex 색상 코드를 입력하고 RGB와 이름을 얻을 수 있다.

해당 App은 24 챕터 "MVVM with RxSwift"에서 배울 MVVM 설계 패턴을 사용하여 구성된다. ViewModel에는 ViewController가 View를 제어하는 데 사용할 다음 논리가 포함되어 있으며, 이 논리에 대한 테스트는 챕터의 뒷부분에 작성된다.

// Convert hex text to color
color = hexString
    .map { hex in
        guard hex.count == 7 else { return .clear }
        let color = UIColor(hex: hex)
        return color
    }
    .asDriver(onErrorJustReturn: .clear)

// Convert the color to an rgb tuple
rgb = color
    .map { color in
        var red: CGFloat = 0.0
        var green: CGFloat = 0.0
        var blue: CGFloat = 0.0
        color.getRed(&red, green: &green, blue: &blue, alpha: nil)
        let rgb = (Int(red * 255.0), Int(green * 255.0), Int(blue *
                                                             255.0))
        return rgb }
    .asDriver(onErrorJustReturn: (0, 0, 0))

// Convert the hex text to a matching name
colorName = hexString
    .map { hexString in
        let hex = String(hexString.dropFirst())
        if let color = ColorName(rawValue: hex) {
            return "\(color)"
        } else {
            return "--" }
    }
    .asDriver(onErrorJustReturn: "")

이 코드를 테스트하기 전에 RxSwift Operator에 대한 몇 가지 테스트를 작성하여 RxTest에 대해 배우게 될거다.

이번 챕터에서는 XCTest를 사용하여 iOS에서 단위 테스트를 작성하는 데 익숙하다고 생각하고 진행한다. iOS에서 유닛 테스트를 처음 하는 경우 비디오 과정에서 iOS 유닛 및 UI 테스트 시작을 선 수강하길 바란다.

Testing operators with RxTest

RxTest는 RxSwift와 별도의 라이브러리다. RxSwift repo 내에서 호스팅되지만 별도의 Pod 설치 및 import가 필요합니다. RxTest는 RxSwift 코드를 테스트하기 위해 다음과 같은 유용한 추가 기능을 제공한다.

• Test Scheduler - 시간 선형 작업 테스트를 세부적으로 제어할 수 있는 가상 시간 스케줄러.
• Recorded.next(::), Recorded.completed(::) 및 Recorded.error(::) - 테스트에서 지정된 시간에 이러한 이벤트를 관찰 가능한 공장 메서드.

RxTest는 Hot 및 Cold Observable 만들어내어 추가할 수 있다.

What are hot and cold observables?

RxSwift는 Rx 코드를 간소화하고 단순화하기 위해 많은 노력을 기울인다. RxSwift 커뮤니티에는 Hot 및 Cold Observable을 구체적인 type 대신 Observable의 특성으로 생각해야 한다는 의견이 있다.
이것은 구현 세부 사항이지만, 테스트를 제외하고 RxSwift에서 Hot 및 Cold Observable에 대한 많은 이야기들을 볼 수 없기 때문에 주의할 필요가 있다.

• Hot Observable:
  • 구독자가 있는지 여부에 관계없이 리소스를 사용.
  • 구독자가 있는지 여부에 관계없이 요소를 생성.
  • 주로 Behavior Relay와 같은 상태 저장 유형과 함께 사용.
• Cold Observable:
  • 구독 시에만 리소스를 사용.
  • 구독자가 있는 경우에만 요소를 생성.
  • 네트워킹과 같은 비동기 작업에 주로 사용.

곧 작성할 단위 테스트에서는 Hot Observable를 사용하겠지만, 이러한 차이를 알고 있는 경우 Cold Observable을 사용해야 할 수도 있다.

class TestingOperators : XCTestCase {
  var scheduler: TestScheduler!
  var subscription: Disposable!

  override func setUp() {
    super.setUp()
    // 테스트 사례가 시작되기 전에 호출되는 setUp() 메서드에서 초기 클럭 값 0으로 새 스케줄러를 초기화
    scheduler = TestScheduler(initialClock: 0)
  }

  override func tearDown() {
    // 테스트 사례가 종료되고 테스트 구독을 1000초의 가상 시간 단위로 폐기하도록 예약하고 스케줄러를 nil으로 설정하여 메모리를 해제
    scheduler.scheduleAt(1000) {
      self.subscription.dispose()
    }
    scheduler = nil
    super.tearDown()
  }

  // amb(_:)는 amb(_:)로 엮인 여러 시퀀스 중에서 가장 먼저 이벤트를 발생시킨 시퀀스의 이벤트만 전달
  func test_Amb() {
    let observer = scheduler.createObserver(String.self)
    let observableA = scheduler.createHotObservable([
      .next(100, "a"),
      .next(200, "b"),
      .next(300, "c")
    ])

    let observableB = scheduler.createHotObservable([
      .next(90, "1"),
      .next(200, "2"),
      .next(300, "3")
    ])

    let ambObservable = observableA.amb(observableB)
    self.subscription = ambObservable.subscribe(observer)
    scheduler.start()

    let results = observer.events.compactMap {
      $0.value.element
    }

    XCTAssertEqual(results, ["1", "2", "3"])
  }

  // filter(_:)는 시퀀스 중에서 조건에 일치하는 이벤트만 전달
  func test_Filter() {
    let observer = scheduler.createObserver(Int.self)
    let observable = scheduler.createHotObservable([
      .next(100, 1),
      .next(200, 2),
      .next(300, 3),
      .next(400, 2),
      .next(500, 1)
    ])

    let filterObservable = observable.filter {
      $0 < 3
    }

    scheduler.scheduleAt(0) {
      self.subscription = filterObservable.subscribe(observer)
    }

    scheduler.start()

    let results = observer.events.compactMap {
      $0.value.element
    }

    XCTAssertEqual(results, [1, 2, 2, 1])
  }
}

Using RxBlocking

RxBlocking은 자체 pod가 있는 RxSwift repo에 포함된 또 다른 라이브러리이며 별도로 import 해야한다.

주요 목적은 observable을 BlockingObservable로 toBlocking(timeout:) 메서드를 통해서 변환하는 것! 이렇게 하면 정상적으로 또는 시간 초과에 도달하여 관찰 가능한 스레드가 종료될 때까지 현재 스레드를 차단한다.

timeout에 전달하는 인자는 optional TimeInterval 타입으로 기본값은 nil이다. 만약 timeout 값을 설정하고 observable이 정상적으로 종료되기 전에 해당 interval이 경과하면, toBlocking 메서드에서는 RxError.timeout 오류를 던지게 된다. 이는 본질적으로 비동기식 작업을 동기식 작업으로 변환하므로 테스트가 훨씬 쉬워지게 된다.

아래 첫 번째 예제에서 toBlocking() 연산자는 ArrayObservable로 변환하여 스케줄러가 생성한 스레드를 종료할 때까지 차단한다. 테스트를 실행하면 비동기식 작업을 테스트하기 위한 세 줄의 코드 성공 여부를 확인할 수 있다.

public enum MaterializedSequenceResult<T> {
  case completed(elements: [T])
  case failed(elements: [T], error: Error)
}

RxBlocking에는 차단 작업의 결과를 조사하는 데 사용할 수 있는 .materialize() operator도 있다. completed / failed 두 개의 케이스와 관련 값을 포함하는 열거형 타입인 MaterializedSequenceResult(MaterializedSequenceResult)가 반환된다.

observable이 성공적으로 종료되면, completed 케이스의 경우 기본 observable들로부터 방출된 요소들의 배열과 관련될 것이다. 그리고 실패하면, failed 케이스는 요소 배열과 오류를 모두 관련 되어 나오게 된다. 아래 두 번째 예제를 보자. 예제는 materialize를 사용하여 toArray 대한 이전 테스트를 다시 구현한다.

  func test_ToArray() throws {
    // 기본 qos로 비동기 테스트를 실행할 동시 스케줄러를 생성.
    let scheduler = ConcurrentDispatchQueueScheduler(qos: .default)

    // 스케줄러에서 두 정수의 observable 구독한 결과를 보유할 observable을 만든다.
    let toArrayObservable = Observable.of(1, 2).subscribeOn(scheduler)

    // ArrayObservable에 대해 Blocking()을 호출한 결과에 대해 toArray를 사용하고, Array로 반환되는 값을 예상된 결과와 expect 한다.
    XCTAssertEqual(try toArrayObservable.toBlocking().toArray(), [1, 2])
  }

  func test_ToArrayMaterialized() {
    // 위와 동일
    let scheduler = ConcurrentDispatchQueueScheduler(qos: .default)
    let toArrayObservable = Observable.of(1, 2).subscribeOn(scheduler)

    // toBlocking()과 materialize()를 observable에 호출하고 결과를 할당
    let result = toArrayObservable
      .toBlocking()
      .materialize()

    // 예상된 결과에 따라 케이스 분리를 통한 expect 분기 비교
    switch result {
    case .completed(let elements):
      XCTAssertEqual(elements,  [1, 2])
    case .failed(_, let error):
      XCTFail(error.localizedDescription)
    }
  }

테스트를 다시 실행하고 모든 테스트가 성공했는지 확인해보자. 보다시피 RxBlocking의 materialize() 사용법은 RxSwift와 다르지만 개념적으로는 유사하다. RxBlocking 버전은 결과를 보다 강력하고 명시적으로 조사하기 위해 결과를 열거형으로 모델링하는 추가 단계를 거친다.
곧 RxBlocking으로 더 많은 작업을 하게 되겠지만, 이제는 operator 테스트에서 벗어나 앱의 프로덕션 코드에 대한 몇 가지 테스트를 작성해보자.

Testing RxSwift production code

import XCTest
import RxSwift
import RxCocoa
import RxTest
@testable import Testing

class TestingViewModel : XCTestCase {
  var viewModel: ViewModel!
  var scheduler: ConcurrentDispatchQueueScheduler!

  override func setUp() {
    super.setUp()

    viewModel = ViewModel()
    scheduler = ConcurrentDispatchQueueScheduler(qos: .default)
  }

  func test_ColorIsRedWhenHexStringIsFF0000_async() {
    let disposeBag = DisposeBag()

    // 나중에 달성할 expectation� 생성
    let expect = expectation(description: #function)

    // 예상되는 테스트 결과를 생성. 예상 색상은 빨강
    let expectedColor = UIColor(red: 1.0, green: 0.0, blue: 0.0, alpha: 1.0)

    // �나중에 할당할 결과를 선언
    var result: UIColor!

    // 뷰 모델의 컬러에 대한 구독을 만듬. 구독 시 드라이버가 초기 요소를 재생하기 때문에 첫 번째 요소는 건너뜀.
    viewModel.color.asObservable()
      .skip(1)
      .subscribe(onNext: {
        // 다음 이벤트 요소를 결과에 할당하고 expect의 fulfill()을 호출합니다.
        result = $0
        expect.fulfill()
      })
      .disposed(by: disposeBag)

    // 뷰 모델의 hexString에 "#ff0000" 문자열 주입
    viewModel.hexString.accept("#ff0000")

    // 1초간의 타임아웃으로 기대에 부응할 때까지 대기. 클로저에서 error를 guard
    waitForExpectations(timeout: 1.0) { error in
      guard error == nil else {
        XCTFail(error!.localizedDescription)
        return
      }

      // 다음 예상 색상이 실제 결과와 같다고 expect 비교
      XCTAssertEqual(expectedColor, result)
    }
  }

  func test_ColorIsRedWhenHexStringIsFF0000() throws {
    // colorObservable을 만들어 동시 스케줄러에서 구독한 결과를 유지
    let colorObservable = viewModel.color.asObservable().subscribeOn(scheduler)

    // 뷰 모델의 hexString에 "#ff0000" 문자열 주입
    viewModel.hexString.accept("#ff0000")

    // colorObservable를 toBlocking()하고 첫 번째 요소가 방출될 때까지 대기. 예상 색상을 결과와 같다고 expect 비교
    XCTAssertEqual(try colorObservable.toBlocking(timeout: 1.0).first(),
                   .red)
  }

  func test_RgbIs010WhenHexStringIs00FF00() throws {
    // 스케줄러에서 구독할 rgbObservable을 생성
    let rgbObservable = viewModel.rgb.asObservable().subscribeOn(scheduler)

    // 뷰 모델의 hexString에 "#00ff00" 문자열 주입
    viewModel.hexString.accept("#00ff00")

    // blocking 된 rgbOservable로 호출한 첫 번째 결과를 검색한 다음 각 값이 결과와 같다고 expect 비교
    let result = try rgbObservable.toBlocking().first()!

    // 0에서 1로, 0에서 255로 변환한 것은 단지 테스트 이름과 일치하고 따라 하기 쉽게 하기 위해
    XCTAssertEqual(0 * 255, result.0)
    XCTAssertEqual(1 * 255, result.1)
    XCTAssertEqual(0 * 255, result.2)
  }

  func testColorNameIsRayWenderlichGreenWhenHexStringIs006636() throws {
    // 스케줄러에서 구독할 colorNameObservable을 생성
    let colorNameObservable = viewModel.colorName.asObservable().subscribeOn(scheduler)

    // 뷰 모델의 hexString에 "#006636" 문자열 주입
    viewModel.hexString.accept("#006636")

    // 다음 각 값이 결과와 같다고 expect 비교
    XCTAssertEqual("rayWenderlichGreen", try colorNameObservable.toBlocking().first()!)
  }
}

"헹구고 반복하라"는 말이 떠오르지만 좋은 의미로 읽힌다. 테스트는 항상 이렇게 쉬워야 한다.
Command-U를 눌러 이 프로젝트의 모든 테스트를 실행하면 모든 것이 잘 전달된다

Where to go from here?

RxText 및 RxBlocking을 사용하여 테스트를 작성하는 것은 RxSwift 및 RxCocoa를 사용하여 데이터 및 UI 바인딩 코드를 작성하는 것과 유사하다. 24 챕터 "MVVM with RxSwift"에서 더 많은 뷰 모델 테스트를 수행할 예정이며 그 때 가서 다시 만나보자