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:
- This is the NewsServicePublisherTest class declaration which extends the PublisherVerification class.
- 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.
- 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).
- 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 NewsServicePublisher. It is assumed that the Publisher is flexible enough to be able to provide the given number of elements. In 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.