rxswift中hud

by Navdeep Singh

通过Navdeep Singh

如何在RxSwift中运行测试 (How to run tests in RxSwift)

RxTest and RxBlocking are part of the RxSwift repository. They are made available via separate pods, however, and so require separate imports.

RxTest和RxBlocking是RxSwift存储库的一部分。 但是，它们是通过单独的容器提供的，因此需要单独导入。

RxTest provides useful additions for testing Rx code. It includes TestScheduler, which is a virtual time scheduler, and provides methods for adding events at precise time intervals.

RxTest为测试Rx代码提供了有用的补充。 它包括TestScheduler (这是一个虚拟的时间计划程序)，并提供了以精确的时间间隔添加事件的方法。

RxBlocking, on the other hand, enables you to convert a regular Observable sequence to a blocking observable, which blocks the thread it’s running on until the observable sequence completes or a specified timeout is reached. This makes testing asynchronous operations much easier.

另一方面， RxBlocking使您可以将常规的Observable序列转换为阻塞的Observable，这将阻塞正在运行的线程，直到Observable序列完成或达到指定的超时为止。 这使测试异步操作变得更加容易。

Let’s look at each one now.

让我们现在看看每个。

接收测试 (RxTest)

As described above, RxTest is part of the same repository as RxSwift. There is one more thing to know about RxTest before we dive into some RxTesting: RxTest exposes two types of Observables for testing purposes.

如上所述， RxTest与RxSwift是同一存储库的一部分。 在深入研究RxTesting之前，还需要了解有关RxTest的另一件事：RxTest出于测试目的公开了两种类型的Observable。

• HotObservables
  热点观察
• ColdObservables
  冷观测

HotObservables replay events at specified times using a test scheduler, regardless of whether there are any subscribers.

HotObservables使用测试计划程序在指定的时间重放事件，而不管是否有订阅者。

ColdObservables work more like regular Observables, replaying their elements to their new subscribers upon subscription.

ColdObservables的工作方式与常规Observables相似，在订阅时将其元素重播给新订阅者。

Rx阻止 (RxBlocking)

If you are familiar with expectations in XCTest, you will know that it’s another way to test asynchronous operations. Using RxBlocking just happens to be way easier. Let’s start with a small implementation so we can see how to take advantage of this library while testing asynchronous operations.

如果您熟悉XCTest中的期望，您将知道这是测试异步操作的另一种方法。 使用RxBlocking只是更容易。 让我们从一个小的实现开始，以便我们可以看到在测试异步操作时如何利用该库。

使用RxBlocking进行测试 (Testing with RxBlocking)

We will start a new test and create an Observable of 10, 20, and 30, as follows:

我们将开始一个新的测试，并创建一个10、20和30的Observable，如下所示：

func testBlocking(){        let observableToTest = Observable.of(10, 20, 30)    }

Now we will define the result as equal to calling toBlocking() on the observable we created:

现在，我们将定义的结果等于在我们创建的可观察对象上调用toBlocking()：

let result = observableToTest.toBlocking()

toBlocking() returns a blocking Observable to a straight array, as you can see here:

toBlocking()将阻塞的Observable返回到直线数组，如您在此处看到的：

We will need to use the first method if we want to discover which is a throwing method. So we will wrap it in a do catch statement, and then we will add an AssertEquals statement if it is successful, as follows:

如果要发现哪种方法是投掷方法，则需要使用第一种方法。 因此，我们将其包装在do catch语句中，然后，如果成功，则将添加AssertEquals语句，如下所示：

func testBlocking(){        let observableToTest = Observable.of(10, 20, 30)        do{            let result = try observableToTest.toBlocking().first()            XCTAssertEqual(result, 10)        } catch {        }    }

Alternatively, an Assert fails if it’s not this:

或者，如果不是，则断言失败：

do{            let result = try observableToTest.toBlocking().first()            XCTAssertEqual(result, 10)        } catch {            XCTFail(error.localizedDescription)        }

That’s it! Let’s run the test, and you will see that the test passes. We can simplify this test with just two lines of code by forcing the try.

而已！ 让我们运行测试，您将看到测试通过。 通过强制尝试，我们可以仅用两行代码来简化此测试。

Again, this is more acceptable on test than production code. We will comment out the do catch statement and then write the assert equals in a single line, as follows:

同样，在测试中这比生产代码更可接受。 我们将注释掉do catch语句，然后在一行中编写断言等于，如下所示：

XCTAssertEqual(try! observableToTest.toBlocking().first(), 10)

Rerun the test, and you will see that the test passes once again. The overall code with comments looks like this:

重新运行测试，您将看到测试再次通过。 带有注释的整体代码如下所示：

func testBlocking(){        let observableToTest = Observable.of(10, 20, 30)//        do{//            let result = try observableToTest.toBlocking().first()//            XCTAssertEqual(result, 10)//        } catch {//            XCTFail(error.localizedDescription)//        }        XCTAssertEqual(try! observableToTest.toBlocking().first(), 10)    }

How’s that for succinct? Truth be told, that Observable sequence would actually be synchronous already if we printed emitted elements in a subscription to it followed by a marker. The marker will be printed after the subscription’s completed event.

那个怎么样？ 实话实说，如果我们在订阅中先打印发出的元素，再加上标记，那么Observable序列实际上实际上已经是同步的。 订阅完成事件后，将打印标记。

To test an actual asynchronous operation, we will write one more test. This time, we will use a concurrent scheduler on a background thread, as follows:

为了测试实际的异步操作，我们将再编写一个测试。 这次，我们将在后台线程上使用并发调度程序，如下所示：

func testAsynchronousToArry(){        let scheduler = ConcurrentDispatchQueueScheduler(qos: .background)    }

Now, we will create an Observable of the simple sequence of integers. We will use map to double each value, as follows:

现在，我们将创建一个简单的整数序列的Observable。 我们将使用map将每个值加倍，如下所示：

let intObservbale = Observable.of(10, 20, 30)            .map{ $0 * 2 }

Then, we will subscribe on the scheduler:

然后，我们将订阅调度程序：

let intObservbale = Observable.of(10, 20, 30)            .map{ $0 * 2 }            .subscribeOn(scheduler)

Now we will write a do catch statement that is similar to the last test and calls toBlocking on the Observable, which should be observed on the main scheduler, as follows:

现在，我们将编写一个与上一个测试类似的do catch语句，并在Observable上调用toBlocking，应在主调度程序上对其进行观察，如下所示：

do{   let result = try intObservbale.observeOn(MainScheduler.instance).toBlocking().toArray()   } catch {   }

Then, we will add the same assertions as the previous example:

然后，我们将添加与先前示例相同的断言：

do{   let result = try intObservbale.observeOn(MainScheduler.instance).toBlocking().toArray()            XCTAssertEqual(result, [20, 40, 60])        } catch {            XCTFail(error.localizedDescription)        }

Now we will run the test, and you will note that it passes with the green check mark in the gutter.

现在，我们将运行测试，您会注意到它通过了带有槽中绿色复选标记的测试。

Note that the marker is printed before the emitted elements in the console, as shown:

请注意，标记在控制台中发出的元素之前打印，如下所示：

This is because these operations were executed asynchronously.

这是因为这些操作是异步执行的。

For other updates you can follow me on Twitter on my twitter handle @NavRudraSambyal

对于其他更新，您可以在我的Twitter句柄@NavRudraSambyal的Twitter上关注我。

To work with examples of hot and cold observables, you can find the link to my book Reactive programming in Swift 4

要处理冷热观测的示例，可以找到我的书《 Swift 4中的React式编程》的链接。

Thanks for reading, please share it if you found it useful :)

感谢您的阅读，如果您觉得有用，请分享：)

翻译自: https://www.freecodecamp.org/news/testing-in-rxswift-2b6eeaeaf432/

rxswift中hud