官术网_书友最值得收藏!

The Publisher verification

Along with the understanding of the importance of the Reactive Streams TCK, it is necessary to get the essential knowledge of the toolkit usage. To acquire a basic knowledge of how this kit works, we are going to verify one of the components of our news service. Since a Publisher is an essential part of our system, we are going to start with its analysis. As we remember, TCK provides org.reactivestreams.tck.PublisherVerification to check the fundamental behavior of the Publisher. In general, PublisherVerification is an abstract class which mandates us to extend just two methods. Let's take a look at the following example in order to understand how to write a verification of the previously developed NewsServicePublisher:

public class NewsServicePublisherTest                              // (1)
extends PublisherVerification<NewsLetter> ... { //

public StreamPublisherTest() { // (2)
super(new TestEnvironment(...)); //
} //

@Override // (3)
public Publisher<NewsLetter> createPublisher(long elements) { //
...
prepareItemsInDatabase(elements); // (3.1)
Publisher<NewsLetter> newsServicePublisher = //
new NewsServicePublisher(...); //
... //
return newsServicePublisher; //
} //

@Override // (4)
public Publisher<NewsLetter> createFailedPublisher() { //
stopDatabase() // (4.1)
return new NewsServicePublisher(...); //
} //

... //
}

The key is as follows:

  1. This is the NewsServicePublisherTest class declaration which extends the PublisherVerification class.
  2. This is the no-args constructor declaration. It should be noted that PublisherVerification does not have the default constructor and mandates the person who implements it to provide the TestEnvironment that is responsible for specific configurations for the test, such as configurations of timeouts and debug logs.
  3. This is the createPublisher method implementation. This method is responsible for generating a Publisher, which produces a given number of elements. In turn, in our case, to satisfy the tests' requirements, we have to fill the database with a certain amount of news entries (3.1).
  4. This is the createFailedPublisher method implementation. Here, in contrast to the createPublisher method, we have to provide a failed instance of the NewsServicePublisher. One of the options in which we have a failed Publisher is when the data source is unavailable, which in our case causes the failure of the NewsServicePublisher(4.1)

The preceding test expands the basic configurations required in order to run the verification of the NewsServicePublisherIt is assumed that the Publisher is flexible enough to be able to provide the given number of elementsIn other words, the test can tell the Publisher how many elements it should produce and whether it should fail or work normally. On the other hand, there are a lot of specific cases where the Publisher is limited to only one element. For example, as we might remember, the NewsPreparationOperator responds with only one element, regardless of the number of incoming elements from the upstream.

By simply following the mentioned configurations of the test, we cannot check the accuracy of that Publisher since many test-cases assume the presence of more than one element in the stream. Fortunately, the Reactive Streams TCK respects such corner cases and allows setting up an additional method called maxElementsFromPublisher() which returns a value that indicates the maximum number of produced elements:

@Override
public long maxElementsFromPublisher() {
return 1;
}

On the one hand, by overriding that method, the tests that require more than one element are skipped. On the other hand, the coverage of the Reactive Streams rules is decreased and may require implementation of the custom test-cases.

主站蜘蛛池模板: 抚宁县| 江城| 乌鲁木齐县| 五原县| 封丘县| 荔波县| 云霄县| 潜江市| 崇明县| 渭南市| 兴文县| 澄城县| 宁波市| 富锦市| 临湘市| 海门市| 珲春市| 昆山市| 通海县| 达拉特旗| 余庆县| 罗城| 宁乡县| 桃江县| 湖州市| 原平市| 古浪县| 阜新市| 特克斯县| 沈阳市| 陈巴尔虎旗| 弋阳县| 洪洞县| 盐池县| 华亭县| 建瓯市| 易门县| 海林市| 莲花县| 甘肃省| 昭平县|