IdentityProcessorVerification (reactive-streams-tck 1.0.2 API)

java.lang.Object
- org.reactivestreams.tck.WithHelperPublisher<T>
- - org.reactivestreams.tck.IdentityProcessorVerification<T>

All Implemented Interfaces:: PublisherVerificationRules, SubscriberWhiteboxVerificationRules

public abstract class IdentityProcessorVerification<T>
extends WithHelperPublisher<T>
implements SubscriberWhiteboxVerificationRules, PublisherVerificationRules

Nested Class Summary

Nested Classes
Modifier and Type Class Description

class IdentityProcessorVerification.ManualSubscriberWithErrorCollection<A>

class IdentityProcessorVerification.TestSetup

Nested Classes
Modifier and Type	Class	Description
`class`	`IdentityProcessorVerification.ManualSubscriberWithErrorCollection<A>`
`class`	`IdentityProcessorVerification.TestSetup`

Constructor Summary

Constructors
Constructor	Description
`IdentityProcessorVerification(TestEnvironment env)`	Test class must specify the expected time it takes for the publisher to shut itself down when the the last downstream `Subscription` is cancelled.
`IdentityProcessorVerification(TestEnvironment env, long publisherReferenceGCTimeoutMillis)`	Test class must specify the expected time it takes for the publisher to shut itself down when the the last downstream `Subscription` is cancelled.
`IdentityProcessorVerification(TestEnvironment env, long publisherReferenceGCTimeoutMillis, int processorBufferSize)`	Test class must specify the expected time it takes for the publisher to shut itself down when the the last downstream `Subscription` is cancelled.

Method Summary

All Methods Instance Methods Abstract Methods Concrete Methods
Modifier and Type	Method	Description
`long`	`boundedDepthOfOnNextAndRequestRecursion()`	In order to verify rule 3.3 of the reactive streams spec, this number will be used to check if a `Subscription` actually solves the "unbounded recursion" problem by not allowing the number of recursive calls to exceed the number returned by this method.
`abstract org.reactivestreams.Publisher<T>`	`createFailedPublisher()`	By implementing this method, additional TCK tests concerning a "failed" publishers will be run.
`abstract org.reactivestreams.Processor<T,T>`	`createIdentityProcessor(int bufferSize)`	This is the main method you must implement in your test incarnation.
`org.reactivestreams.Publisher<T>`	`createPublisher(long elements)`
`org.reactivestreams.Subscriber<T>`	`createSubscriber(SubscriberWhiteboxVerification.WhiteboxSubscriberProbe<T> probe)`
`boolean`	`doesCoordinatedEmission()`	Override this method and return `true` if the `Processor` returned by the `createIdentityProcessor(int)` coordinates its `Subscriber`s request amounts and only delivers onNext signals if all Subscribers have indicated (via their Subscription#request(long)) they are ready to receive elements.
`long`	`maxElementsFromPublisher()`	Override and return lower value if your Publisher is only able to produce a known number of elements.
`long`	`maxSupportedSubscribers()`	Describes the tested implementation in terms of how many subscribers they can support.
`void`	`mustImmediatelyPassOnOnErrorEventsReceivedFromItsUpstreamToItsDownstream()`
`void`	`notVerified()`
`void`	`notVerified(java.lang.String message)`
`void`	`optional_spec104_mustSignalOnErrorWhenFails()`	Asks for an error `Publisher` that should call `onSubscribe` exactly once followed by a single call to `onError()` without receiving any requests and otherwise not throwing any exception.
`void`	`optional_spec105_emptyStreamMustTerminateBySignallingOnComplete()`	Asks for an empty `Publisher` (i.e., length 0) and verifies it completes in a timely manner.
`void`	`optional_spec111_maySupportMultiSubscribe()`	Asks for a single-element `Publisher` and subscribes to it twice, without consuming with either `Subscriber` instance (i.e., no requests are issued).
`void`	`optional_spec111_multicast_mustProduceTheSameElementsInTheSameSequenceToAllOfItsSubscribersWhenRequestingManyUpfront()`	Asks for a short `Publisher` (length 3), subscribes 3 `Subscriber`s to it, requests more than the length items upfront with each and verifies they all received the same items in the same order (but does not verify they all complete).
`void`	`optional_spec111_multicast_mustProduceTheSameElementsInTheSameSequenceToAllOfItsSubscribersWhenRequestingManyUpfrontAndCompleteAsExpected()`	Asks for a short `Publisher` (length 3), subscribes 3 `Subscriber`s to it, requests more than the length items upfront with each and verifies they all received the same items in the same order followed by an `onComplete` signal.
`void`	`optional_spec111_multicast_mustProduceTheSameElementsInTheSameSequenceToAllOfItsSubscribersWhenRequestingOneByOne()`	Asks for a short `Publisher` (length 5), subscribes 3 `Subscriber`s to it, requests with different patterns and checks if all 3 received the same events in the same order.
`void`	`optional_spec111_registeredSubscribersMustReceiveOnNextOrOnCompleteSignals()`	Asks for a single-element `Publisher` and subscribes to it twice.
`void`	`optional_spec309_requestNegativeNumberMaySignalIllegalArgumentExceptionWithSpecificMessage()`	Asks for a short `Publisher` (length 10) and issues a random, negative `request()` call which should trigger an `onError` call with an `IllegalArgumentException`.
`void`	`optionalMultipleSubscribersTest(long requiredSubscribersSupport, Function<java.lang.Long,IdentityProcessorVerification.TestSetup> body)`	Test for feature that REQUIRES multiple subscribers to be supported by Publisher.
`void`	`required_createPublisher1MustProduceAStreamOfExactly1Element()`	Asks for a `Publisher` that should emit exactly one item and complete (both within a timeout specified by `TestEnvironment.defaultTimeoutMillis()`) in response to a request(1).
`void`	`required_createPublisher3MustProduceAStreamOfExactly3Elements()`	Asks for a `Publisher` that should emit exactly three items and complete (all within a timeout specified by `TestEnvironment.defaultTimeoutMillis()`).
`void`	`required_exerciseWhiteboxHappyPath()`
`void`	`required_mustRequestFromUpstreamForElementsThatHaveBeenRequestedLongAgo()`	Asks for a `Processor` that supports at least 2 `Subscriber`s at once and checks requests from `Subscriber`s will eventually lead to requests towards the upstream of the `Processor`.
`void`	`required_spec101_subscriptionRequestMustResultInTheCorrectNumberOfProducedElements()`	Asks for a `Publisher` that responds to a request pattern of 0 (not requesting upfront), 1, 1 and 2 in a timely manner.
`void`	`required_spec102_maySignalLessThanRequestedAndTerminateSubscription()`	Asks for a short `Publisher` and verifies that requesting once and with more than the length (but bounded) results in the correct number of items to be emitted (i.e., length 3 and request 10) followed by an `onComplete` signal.
`void`	`required_spec104_mustCallOnErrorOnAllItsSubscribersIfItEncountersANonRecoverableError()`	Asks for a `Processor` that supports at least 2 `Subscriber`s at once and checks if two `Subscriber`s receive the same items and a terminal `Exception`.
`void`	`required_spec105_mustSignalOnCompleteWhenFiniteStreamTerminates()`	Asks for a short `Publisher` (i.e., length 3) and verifies, after requesting one by one, the sequence completes normally.
`void`	`required_spec107_mustNotEmitFurtherSignalsOnceOnCompleteHasBeenSignalled()`	Asks for a single-element `Publisher` and checks if requesting after the terminal event doesn't lead to more items or terminal signals to be emitted.
`void`	`required_spec109_mayRejectCallsToSubscribeIfPublisherIsUnableOrUnwillingToServeThemRejectionMustTriggerOnErrorAfterOnSubscribe()`	Asks for an error `Publisher` that should call `onSubscribe` exactly once followed by a single call to `onError()` without receiving any requests.
`void`	`required_spec109_mustIssueOnSubscribeForNonNullSubscriber()`	Asks for an empty `Publisher` and verifies if `onSubscribe` signal was emitted before any other `onNext`, `onError` or `onComplete` signal.
`void`	`required_spec109_subscribeThrowNPEOnNullSubscriber()`	Asks for an empty `Publisher` and calls `subscribe` on it with `null` that should result in a `NullPointerException` to be thrown.
`void`	`required_spec201_mustSignalDemandViaSubscriptionRequest()`
`void`	`required_spec203_mustNotCallMethodsOnSubscriptionOrPublisherInOnComplete()`
`void`	`required_spec203_mustNotCallMethodsOnSubscriptionOrPublisherInOnError()`
`void`	`required_spec205_mustCallSubscriptionCancelIfItAlreadyHasAnSubscriptionAndReceivesAnotherOnSubscribeSignal()`
`void`	`required_spec208_mustBePreparedToReceiveOnNextSignalsAfterHavingCalledSubscriptionCancel()`
`void`	`required_spec209_mustBePreparedToReceiveAnOnCompleteSignalWithoutPrecedingRequestCall()`
`void`	`required_spec209_mustBePreparedToReceiveAnOnCompleteSignalWithPrecedingRequestCall()`
`void`	`required_spec210_mustBePreparedToReceiveAnOnErrorSignalWithoutPrecedingRequestCall()`
`void`	`required_spec210_mustBePreparedToReceiveAnOnErrorSignalWithPrecedingRequestCall()`
`void`	`required_spec213_onError_mustThrowNullPointerExceptionWhenParametersAreNull()`
`void`	`required_spec213_onNext_mustThrowNullPointerExceptionWhenParametersAreNull()`
`void`	`required_spec213_onSubscribe_mustThrowNullPointerExceptionWhenParametersAreNull()`
`void`	`required_spec302_mustAllowSynchronousRequestCallsFromOnNextAndOnSubscribe()`	Asks for a short `Publisher` (length 6), requests several times from within `onSubscribe` and then requests one-by-one from `onNext`.
`void`	`required_spec303_mustNotAllowUnboundedRecursion()`	Asks for a `Publisher` with length equal to the value returned by `PublisherVerificationRules.required_validate_boundedDepthOfOnNextAndRequestRecursion()` plus 1, calls `request(1)` externally and then from within `onNext` and checks if the stack depth did not increase beyond the amount permitted by `PublisherVerificationRules.required_validate_boundedDepthOfOnNextAndRequestRecursion()`.
`void`	`required_spec306_afterSubscriptionIsCancelledRequestMustBeNops()`	Asks for a short `Publisher` (length 3) and verifies that cancelling without requesting anything, then requesting items should result in no signals to be emitted.
`void`	`required_spec307_afterSubscriptionIsCancelledAdditionalCancelationsMustBeNops()`	Asks for a single-element `Publisher` and verifies that without requesting anything, cancelling the sequence multiple times should result in no signals to be emitted and should result in an thrown exception.
`void`	`required_spec308_requestMustRegisterGivenNumberElementsToBeProduced()`
`void`	`required_spec309_requestNegativeNumberMustSignalIllegalArgumentException()`	Asks for a short `Publisher` (length 10) and issues a random, negative `request()` call which should trigger an `onError` call with an `IllegalArgumentException`.
`void`	`required_spec309_requestZeroMustSignalIllegalArgumentException()`	Asks for a short `Publisher` (length 10) and issues a `request(0)` which should trigger an `onError` call with an `IllegalArgumentException`.
`void`	`required_spec312_cancelMustMakeThePublisherToEventuallyStopSignaling()`	Asks for a short `Publisher` (length 20), requests some items (less than the length), consumes one item then cancels the sequence and verifies the publisher emitted at most the requested amount and stopped emitting (or terminated).
`void`	`required_spec313_cancelMustMakeThePublisherEventuallyDropAllReferencesToTheSubscriber()`	Asks for a short `Publisher` (length 3) requests and consumes one element from it, cancels the `Subscription` , calls `System.gc()` and then checks if all references to the test `Subscriber` has been dropped (by checking the `WeakReference` has been emptied).
`void`	`required_spec317_mustNotSignalOnErrorWhenPendingAboveLongMaxValue()`	Asks for a very long `Publisher` (up to `Integer.MAX_VALUE`), requests `Long.MAX_VALUE - 1` after each received item and expects no failure due to a potential overflow in the pending emission count while consuming 10 items and cancelling the sequence.
`void`	`required_spec317_mustSupportACumulativePendingElementCountUpToLongMaxValue()`	Asks for a short `Publisher` (length 3) and requests `Long.MAX_VALUE` from it in total (split across two `Long.MAX_VALUE / 2` and one `request(1)`), verifying that the `Publisher` emits all of its items and completes normally.
`void`	`required_spec317_mustSupportAPendingElementCountUpToLongMaxValue()`	Asks for a short `Publisher` (length 3) and requests `Long.MAX_VALUE` from it, verifying that the `Publisher` emits all of its items and completes normally and does not keep spinning attempting to fulfill the `Long.MAX_VALUE` demand by some means.
`void`	`required_validate_boundedDepthOfOnNextAndRequestRecursion()`	Validates that the override of `PublisherVerification.boundedDepthOfOnNextAndRequestRecursion()` returns a positive value.
`void`	`required_validate_maxElementsFromPublisher()`	Validates that the override of `PublisherVerification.maxElementsFromPublisher()` returns a non-negative value.
`void`	`setUp()`
`boolean`	`skipStochasticTests()`	Override and return `true` in order to skip executing tests marked as `Stochastic`.
`void`	`stochastic_spec103_mustSignalOnMethodsSequentially()`	Asks for a short `Publisher` (i.e., length 10), repeatedly subscribes to this `Publisher`, requests items one by one and verifies the `Publisher` calls the `onXXX` methods non-overlappingly.
`void`	`untested_spec106_mustConsiderSubscriptionCancelledAfterOnErrorOrOnCompleteHasBeenCalled()`	Currently, this test is skipped because it is unclear this rule can be effectively checked on a `Publisher` instance without looking into or hooking into the implementation of it.
`void`	`untested_spec107_mustNotEmitFurtherSignalsOnceOnErrorHasBeenSignalled()`	Currently, this test is skipped, although it is possible to validate an error `Publisher` along the same lines as `PublisherVerificationRules.required_spec107_mustNotEmitFurtherSignalsOnceOnCompleteHasBeenSignalled()`.
`void`	`untested_spec108_possiblyCanceledSubscriptionShouldNotReceiveOnErrorOrOnCompleteSignals()`	Currently, this test is skipped because there was no agreement on how to verify its "eventually" requirement.
`void`	`untested_spec109_subscribeShouldNotThrowNonFatalThrowable()`	Currently, this test is skipped because there is no common agreement on what is to be considered a fatal exception and besides, `Publisher.subscribe` is only allowed throw a `NullPointerException` and any other exception would require looking into or hooking into the implementation of the `Publisher`.
`void`	`untested_spec110_rejectASubscriptionRequestIfTheSameSubscriberSubscribesTwice()`	Currently, this test is skipped because enforcing rule §1.10 requires unlimited retention and reference-equal checks on all incoming `Subscriber` which is generally infeasible, plus reusing the same `Subscriber` instance is better detected (or ignored) inside `Subscriber.onSubscribe` when the method is called multiple times.
`void`	`untested_spec202_shouldAsynchronouslyDispatch()`
`void`	`untested_spec204_mustConsiderTheSubscriptionAsCancelledInAfterRecievingOnCompleteOrOnError()`
`void`	`untested_spec206_mustCallSubscriptionCancelIfItIsNoLongerValid()`
`void`	`untested_spec207_mustEnsureAllCallsOnItsSubscriptionTakePlaceFromTheSameThreadOrTakeCareOfSynchronization()`
`void`	`untested_spec211_mustMakeSureThatAllCallsOnItsMethodsHappenBeforeTheProcessingOfTheRespectiveEvents()`
`void`	`untested_spec212_mustNotCallOnSubscribeMoreThanOnceBasedOnObjectEquality_specViolation()`
`void`	`untested_spec213_failingOnSignalInvocation()`
`void`	`untested_spec301_mustNotBeCalledOutsideSubscriberContext()`
`void`	`untested_spec304_requestShouldNotPerformHeavyComputations()`	Currently, this test is skipped because a `request` could enter into a synchronous computation via `onNext` legally and otherwise there is no common agreement how to detect such heavy computation reliably.
`void`	`untested_spec305_cancelMustNotSynchronouslyPerformHeavyComputation()`	Currently, this test is skipped because there is no reliable agreed upon way to detect a heavy computation.
`void`	`untested_spec310_requestMaySynchronouslyCallOnNextOnSubscriber()`
`void`	`untested_spec311_requestMaySynchronouslyCallOnCompleteOrOnError()`
`void`	`untested_spec314_cancelMayCauseThePublisherToShutdownIfNoOtherSubscriptionExists()`
`void`	`untested_spec315_cancelMustNotThrowExceptionAndMustSignalOnError()`
`void`	`untested_spec316_requestMustNotThrowExceptionAndMustOnErrorTheSubscriber()`

Methods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Methods inherited from class org.reactivestreams.tck.WithHelperPublisher
createElement, createHelperPublisher, publisherExecutorService

- Constructor Detail
  - IdentityProcessorVerification
```
public IdentityProcessorVerification(TestEnvironment env)
```
    Test class must specify the expected time it takes for the publisher to shut itself down when the the last downstream Subscription is cancelled. The processor will be required to be able to buffer TestEnvironment.TEST_BUFFER_SIZE elements.
  - IdentityProcessorVerification
```
public IdentityProcessorVerification(TestEnvironment env,
                                     long publisherReferenceGCTimeoutMillis)
```
    Test class must specify the expected time it takes for the publisher to shut itself down when the the last downstream Subscription is cancelled. The processor will be required to be able to buffer TestEnvironment.TEST_BUFFER_SIZE elements.
    
    Parameters:
    
    publisherReferenceGCTimeoutMillis - used to determine after how much time a reference to a Subscriber should be already dropped by the Publisher.
  - IdentityProcessorVerification
```
public IdentityProcessorVerification(TestEnvironment env,
                                     long publisherReferenceGCTimeoutMillis,
                                     int processorBufferSize)
```
    Test class must specify the expected time it takes for the publisher to shut itself down when the the last downstream Subscription is cancelled.
    
    Parameters:
    
    publisherReferenceGCTimeoutMillis - used to determine after how much time a reference to a Subscriber should be already dropped by the Publisher.
    
    processorBufferSize - number of elements the processor is required to be able to buffer.
- Method Detail
  - createIdentityProcessor
```
public abstract org.reactivestreams.Processor<T,T> createIdentityProcessor(int bufferSize)
```
    This is the main method you must implement in your test incarnation. It must create a Processor, which simply forwards all stream elements from its upstream to its downstream. It must be able to internally buffer the given number of elements.
    
    Parameters:
    
    bufferSize - number of elements the processor is required to be able to buffer.
  - createFailedPublisher
```
public abstract org.reactivestreams.Publisher<T> createFailedPublisher()
```
    By implementing this method, additional TCK tests concerning a "failed" publishers will be run. The expected behaviour of the Publisher returned by this method is hand out a subscription, followed by signalling onError on it, as specified by Rule 1.9. If you want to ignore these additional tests, return null from this method.
  - maxElementsFromPublisher
```
public long maxElementsFromPublisher()
```
    Override and return lower value if your Publisher is only able to produce a known number of elements. For example, if it is designed to return at-most-one element, return 1 from this method. Defaults to Long.MAX_VALUE - 1, meaning that the Publisher can be produce a huge but NOT an unbounded number of elements. To mark your Publisher will *never* signal an onComplete override this method and return Long.MAX_VALUE, which will result in *skipping all tests which require an onComplete to be triggered* (!).
  - boundedDepthOfOnNextAndRequestRecursion
```
public long boundedDepthOfOnNextAndRequestRecursion()
```
    In order to verify rule 3.3 of the reactive streams spec, this number will be used to check if a Subscription actually solves the "unbounded recursion" problem by not allowing the number of recursive calls to exceed the number returned by this method.
    
    See Also:
    
    reactive streams spec, rule 3.3, PublisherVerification.required_spec303_mustNotAllowUnboundedRecursion()
  - skipStochasticTests
```
public boolean skipStochasticTests()
```
    Override and return true in order to skip executing tests marked as Stochastic. Such tests MAY sometimes fail even though the impl
  - maxSupportedSubscribers
```
public long maxSupportedSubscribers()
```
    Describes the tested implementation in terms of how many subscribers they can support. Some tests require the Publisher under test to support multiple Subscribers, yet the spec does not require all publishers to be able to do so, thus – if an implementation supports only a limited number of subscribers (e.g. only 1 subscriber, also known as "no fanout") you MUST return that number from this method by overriding it.
  - doesCoordinatedEmission
```
public boolean doesCoordinatedEmission()
```
    Override this method and return true if the Processor returned by the createIdentityProcessor(int) coordinates its Subscribers request amounts and only delivers onNext signals if all Subscribers have indicated (via their Subscription#request(long)) they are ready to receive elements.
  - setUp
```
public void setUp()
           throws java.lang.Exception
```
    Throws:
    
    java.lang.Exception
  - createPublisher
```
public org.reactivestreams.Publisher<T> createPublisher(long elements)
```
  - required_validate_maxElementsFromPublisher
```
public void required_validate_maxElementsFromPublisher()
                                                throws java.lang.Exception
```
    Description copied from interface: PublisherVerificationRules
    
    Validates that the override of PublisherVerification.maxElementsFromPublisher() returns a non-negative value.
    
    Specified by:
    
    required_validate_maxElementsFromPublisher in interface PublisherVerificationRules
    
    Throws:
    
    java.lang.Exception
  - required_validate_boundedDepthOfOnNextAndRequestRecursion
```
public void required_validate_boundedDepthOfOnNextAndRequestRecursion()
                                                               throws java.lang.Exception
```
    Description copied from interface: PublisherVerificationRules
    
    Validates that the override of PublisherVerification.boundedDepthOfOnNextAndRequestRecursion() returns a positive value.
    
    Specified by:
    
    required_validate_boundedDepthOfOnNextAndRequestRecursion in interface PublisherVerificationRules
    
    Throws:
    
    java.lang.Exception
  - required_createPublisher1MustProduceAStreamOfExactly1Element
```
public void required_createPublisher1MustProduceAStreamOfExactly1Element()
                                                                  throws java.lang.Throwable
```
    Description copied from interface: PublisherVerificationRules
    Asks for a Publisher that should emit exactly one item and complete (both within a timeout specified by TestEnvironment.defaultTimeoutMillis()) in response to a request(1).
    The test is not executed if PublisherVerification.maxElementsFromPublisher() returns zero. If this test fails, the following could be checked within the Publisher implementation:
    - the Publisher.subscribe(Subscriber) method has actual implementation,
    - in the Publisher.subscribe(Subscriber) method, if there is an upstream Publisher, that Publisher is actually subscribed to,
    - if the Publisher is part of a chain, all elements actually issue a request() call in response to the test subscriber or by default to their upstream,
    - in the Publisher.subscribe(Subscriber) method, the Subscriber.onSubscribe is called as part of the preparation process (usually before subscribing to other Publishers),
    - if the Publisher implementation works for a consumer that calls request(1),
    - if the Publisher implementation is able to emit an onComplete without requests,
    - that the Publisher implementation does not emit more than the allowed elements (exactly one).
    Specified by:
    
    required_createPublisher1MustProduceAStreamOfExactly1Element in interface PublisherVerificationRules
    
    Throws:
    
    java.lang.Throwable
  - required_createPublisher3MustProduceAStreamOfExactly3Elements
```
public void required_createPublisher3MustProduceAStreamOfExactly3Elements()
                                                                   throws java.lang.Throwable
```
    Description copied from interface: PublisherVerificationRules
    Asks for a Publisher that should emit exactly three items and complete (all within a timeout specified by TestEnvironment.defaultTimeoutMillis()).
    The test is not executed if PublisherVerification.maxElementsFromPublisher() is less than 3.
    The tests requests one-by-one and verifies each single response item arrives in time.
    If this test fails, the following could be checked within the Publisher implementation:
    - the Publisher.subscribe(Subscriber) method has actual implementation,
    - in the Publisher.subscribe(Subscriber) method, if there is an upstream Publisher, that Publisher is actually subscribed to,
    - if the Publisher is part of a chain, all elements actually issue a request() call in response to the test subscriber or by default to their upstream,
    - in the Publisher.subscribe(Subscriber) method, the Subscriber.onSubscribe is called as part of the preparation process (usually before subscribing to other Publishers),
    - if the Publisher implementation works for a subscriber that calls request(1) after consuming an item,
    - if the Publisher implementation is able to emit an onComplete without requests.
    Specified by:
    
    required_createPublisher3MustProduceAStreamOfExactly3Elements in interface PublisherVerificationRules
    
    Throws:
    
    java.lang.Throwable
  - required_spec101_subscriptionRequestMustResultInTheCorrectNumberOfProducedElements
```
public void required_spec101_subscriptionRequestMustResultInTheCorrectNumberOfProducedElements()
                                                                                        throws java.lang.Throwable
```
    Description copied from interface: PublisherVerificationRules
    Asks for a Publisher that responds to a request pattern of 0 (not requesting upfront), 1, 1 and 2 in a timely manner.
    Verifies rule: 1.1
    The test is not executed if PublisherVerification.maxElementsFromPublisher() is less than 5.
    This test ensures that the Publisher implementation correctly responds to request() calls that in total are less than the number of elements this Publisher could emit (thus the completion event won't be emitted).
    If this test fails, the following could be checked within the Publisher implementation:
    - the TestEnvironment has large enough timeout specified in case the Publisher has some time-delay behavior,
    - make sure the PublisherVerificationRules.required_createPublisher1MustProduceAStreamOfExactly1Element() and PublisherVerificationRules.required_createPublisher3MustProduceAStreamOfExactly3Elements() tests pass,
    - if the Publisher implementation considers the cumulative request amount it receives,
    - if the Publisher doesn't lose any request() signal and the state transition from idle -> emitting or emitting -> keep emitting works properly.
    Specified by:
    
    required_spec101_subscriptionRequestMustResultInTheCorrectNumberOfProducedElements in interface PublisherVerificationRules
    
    Throws:
    
    java.lang.Throwable
  - required_spec102_maySignalLessThanRequestedAndTerminateSubscription
```
public void required_spec102_maySignalLessThanRequestedAndTerminateSubscription()
                                                                         throws java.lang.Throwable
```
    Description copied from interface: PublisherVerificationRules
    Asks for a short Publisher and verifies that requesting once and with more than the length (but bounded) results in the correct number of items to be emitted (i.e., length 3 and request 10) followed by an onComplete signal.
    Verifies rule: 1.2
    The test is not executed if PublisherVerification.maxElementsFromPublisher() is less than 3.
    This test ensures that the Publisher implementation can deal with larger requests than the number of items it can produce.
    If this test fails, the following could be checked within the Publisher implementation:
    - the TestEnvironment has large enough timeout specified in case the Publisher has some time-delay behavior,
    - make sure the PublisherVerificationRules.required_createPublisher1MustProduceAStreamOfExactly1Element() and PublisherVerificationRules.required_createPublisher3MustProduceAStreamOfExactly3Elements() tests pass.
    Specified by:
    
    required_spec102_maySignalLessThanRequestedAndTerminateSubscription in interface PublisherVerificationRules
    
    Throws:
    
    java.lang.Throwable
  - stochastic_spec103_mustSignalOnMethodsSequentially
```
public void stochastic_spec103_mustSignalOnMethodsSequentially()
                                                        throws java.lang.Throwable
```
    Description copied from interface: PublisherVerificationRules
    Asks for a short Publisher (i.e., length 10), repeatedly subscribes to this Publisher, requests items one by one and verifies the Publisher calls the onXXX methods non-overlappingly.
    Verifies rule: 1.3
    The test is not executed if PublisherVerification.maxElementsFromPublisher() is less than 10.
    Note that this test is probabilistic, that is, may not capture any concurrent invocation in a {code Publisher} implementation. Note also that this test is sensitive to cases when a request() call in onSubscribe() triggers an asynchronous call to the other onXXX methods. In contrast, the test allows synchronous call chain of onSubscribe -> request -> onNext.
    If this test fails, the following could be checked within the Publisher implementation:
    - the TestEnvironment has large enough timeout specified in case the Publisher has some time-delay behavior,
    - make sure the PublisherVerificationRules.required_createPublisher1MustProduceAStreamOfExactly1Element() and PublisherVerificationRules.required_createPublisher3MustProduceAStreamOfExactly3Elements() tests pass,
    - if a request() call from onSubscribe() could trigger an asynchronous call to onNext() and if so, make sure such request() calls are deferred until the call to onSubscribe() returns normally.
    Specified by:
    
    stochastic_spec103_mustSignalOnMethodsSequentially in interface PublisherVerificationRules
    
    Throws:
    
    java.lang.Throwable
  - optional_spec104_mustSignalOnErrorWhenFails
```
public void optional_spec104_mustSignalOnErrorWhenFails()
                                                 throws java.lang.Throwable
```
    Description copied from interface: PublisherVerificationRules
    Asks for an error Publisher that should call onSubscribe exactly once followed by a single call to onError() without receiving any requests and otherwise not throwing any exception.
    Verifies rule: 1.4
    The test is not executed if PublisherVerification.createErrorPublisher() returns null.
    If this test fails, the following could be checked within the error Publisher implementation:
    - the Publisher.subscribe(Subscriber) method has actual implementation,
    - in the Publisher.subscribe(Subscriber) method, if there is an upstream Publisher, that Publisher is actually subscribed to,
    - if the Publisher implementation does signal an onSubscribe before signalling onError,
    - if the Publisher implementation is able to emit an onError without requests,
    - if the Publisher is non-empty as this test requires a Publisher to signal an onError eagerly.
    Specified by:
    
    optional_spec104_mustSignalOnErrorWhenFails in interface PublisherVerificationRules
    
    Throws:
    
    java.lang.Throwable
  - required_spec105_mustSignalOnCompleteWhenFiniteStreamTerminates
```
public void required_spec105_mustSignalOnCompleteWhenFiniteStreamTerminates()
                                                                     throws java.lang.Throwable
```
    Description copied from interface: PublisherVerificationRules
    Asks for a short Publisher (i.e., length 3) and verifies, after requesting one by one, the sequence completes normally.
    Verifies rule: 1.5
    The test is not executed if PublisherVerification.maxElementsFromPublisher() is less than 3.
    Note that the tests requests 1 after the items have been received and before expecting an onComplete signal.
    If this test fails, the following could be checked within the Publisher implementation:
    - the TestEnvironment has large enough timeout specified in case the Publisher has some time-delay behavior,
    - make sure the PublisherVerificationRules.required_createPublisher1MustProduceAStreamOfExactly1Element() and PublisherVerificationRules.required_createPublisher3MustProduceAStreamOfExactly3Elements() tests pass,
    Specified by:
    
    required_spec105_mustSignalOnCompleteWhenFiniteStreamTerminates in interface PublisherVerificationRules
    
    Throws:
    
    java.lang.Throwable
  - optional_spec105_emptyStreamMustTerminateBySignallingOnComplete
```
public void optional_spec105_emptyStreamMustTerminateBySignallingOnComplete()
                                                                     throws java.lang.Throwable
```
    Description copied from interface: PublisherVerificationRules
    Asks for an empty Publisher (i.e., length 0) and verifies it completes in a timely manner.
    Verifies rule: 1.5
    Note that the tests requests 1 before expecting an onComplete signal.
    If this test fails, the following could be checked within the Publisher implementation:
    - the TestEnvironment has large enough timeout specified in case the Publisher has some time-delay behavior,
    - if the Publisher is non-empty as this test requires a Publisher without items.
    Specified by:
    
    optional_spec105_emptyStreamMustTerminateBySignallingOnComplete in interface PublisherVerificationRules
    
    Throws:
    
    java.lang.Throwable
  - untested_spec106_mustConsiderSubscriptionCancelledAfterOnErrorOrOnCompleteHasBeenCalled
```
public void untested_spec106_mustConsiderSubscriptionCancelledAfterOnErrorOrOnCompleteHasBeenCalled()
                                                                                             throws java.lang.Throwable
```
    Description copied from interface: PublisherVerificationRules
    
    Currently, this test is skipped because it is unclear this rule can be effectively checked on a Publisher instance without looking into or hooking into the implementation of it.
    Verifies rule: 1.6
    
    Specified by:
    
    untested_spec106_mustConsiderSubscriptionCancelledAfterOnErrorOrOnCompleteHasBeenCalled in interface PublisherVerificationRules
    
    Throws:
    
    java.lang.Throwable
  - required_spec107_mustNotEmitFurtherSignalsOnceOnCompleteHasBeenSignalled
```
public void required_spec107_mustNotEmitFurtherSignalsOnceOnCompleteHasBeenSignalled()
                                                                              throws java.lang.Throwable
```
    Description copied from interface: PublisherVerificationRules
    Asks for a single-element Publisher and checks if requesting after the terminal event doesn't lead to more items or terminal signals to be emitted.
    Verifies rule: 1.7
    The test is not executed if PublisherVerification.maxElementsFromPublisher() is less than 1.
    The tests requests more items than the expected Publisher length upfront and some more items after its completion.
    If this test fails, the following could be checked within the Publisher implementation:
    - the TestEnvironment has large enough timeout specified in case the Publisher has some time-delay behavior,
    - the indication for the terminal state is properly persisted and a request call can't trigger emission of more items or another terminal signal.
    Specified by:
    
    required_spec107_mustNotEmitFurtherSignalsOnceOnCompleteHasBeenSignalled in interface PublisherVerificationRules
    
    Throws:
    
    java.lang.Throwable
  - untested_spec107_mustNotEmitFurtherSignalsOnceOnErrorHasBeenSignalled
```
public void untested_spec107_mustNotEmitFurtherSignalsOnceOnErrorHasBeenSignalled()
                                                                           throws java.lang.Throwable
```
    Description copied from interface: PublisherVerificationRules
    
    Currently, this test is skipped, although it is possible to validate an error Publisher along the same lines as PublisherVerificationRules.required_spec107_mustNotEmitFurtherSignalsOnceOnCompleteHasBeenSignalled().
    Verifies rule: 1.7
    
    Specified by:
    
    untested_spec107_mustNotEmitFurtherSignalsOnceOnErrorHasBeenSignalled in interface PublisherVerificationRules
    
    Throws:
    
    java.lang.Throwable
  - untested_spec108_possiblyCanceledSubscriptionShouldNotReceiveOnErrorOrOnCompleteSignals
```
public void untested_spec108_possiblyCanceledSubscriptionShouldNotReceiveOnErrorOrOnCompleteSignals()
                                                                                             throws java.lang.Throwable
```
    Description copied from interface: PublisherVerificationRules
    
    Currently, this test is skipped because there was no agreement on how to verify its "eventually" requirement.
    Verifies rule: 1.8
    
    Specified by:
    
    untested_spec108_possiblyCanceledSubscriptionShouldNotReceiveOnErrorOrOnCompleteSignals in interface PublisherVerificationRules
    
    Throws:
    
    java.lang.Throwable
  - untested_spec109_subscribeShouldNotThrowNonFatalThrowable
```
public void untested_spec109_subscribeShouldNotThrowNonFatalThrowable()
                                                               throws java.lang.Throwable
```
    Description copied from interface: PublisherVerificationRules
    
    Currently, this test is skipped because there is no common agreement on what is to be considered a fatal exception and besides, Publisher.subscribe is only allowed throw a NullPointerException and any other exception would require looking into or hooking into the implementation of the Publisher.
    Verifies rule: 1.9
    
    Specified by:
    
    untested_spec109_subscribeShouldNotThrowNonFatalThrowable in interface PublisherVerificationRules
    
    Throws:
    
    java.lang.Throwable
  - required_spec109_subscribeThrowNPEOnNullSubscriber
```
public void required_spec109_subscribeThrowNPEOnNullSubscriber()
                                                        throws java.lang.Throwable
```
    Description copied from interface: PublisherVerificationRules
    
    Asks for an empty Publisher and calls subscribe on it with null that should result in a NullPointerException to be thrown.
    Verifies rule: 1.9
    If this test fails, check if the subscribe() implementation has an explicit null check (or a method dereference on the Subscriber), especially if the incoming Subscriber is wrapped or stored to be used later.
    
    Specified by:
    
    required_spec109_subscribeThrowNPEOnNullSubscriber in interface PublisherVerificationRules
    
    Throws:
    
    java.lang.Throwable
  - required_spec109_mayRejectCallsToSubscribeIfPublisherIsUnableOrUnwillingToServeThemRejectionMustTriggerOnErrorAfterOnSubscribe
```
public void required_spec109_mayRejectCallsToSubscribeIfPublisherIsUnableOrUnwillingToServeThemRejectionMustTriggerOnErrorAfterOnSubscribe()
                                                                                                                                    throws java.lang.Throwable
```
    Description copied from interface: PublisherVerificationRules
    Asks for an error Publisher that should call onSubscribe exactly once followed by a single call to onError() without receiving any requests.
    Verifies rule: 1.9
    The test is not executed if PublisherVerification.createErrorPublisher() returns null.
    The difference between this test and PublisherVerificationRules.optional_spec104_mustSignalOnErrorWhenFails() is that there is no explicit verification if exceptions were thrown in addition to the regular onSubscribe+onError signal pair.
    If this test fails, the following could be checked within the error Publisher implementation:
    - the Publisher.subscribe(Subscriber) method has actual implementation,
    - in the Publisher.subscribe(Subscriber) method, if there is an upstream Publisher, that Publisher is actually subscribed to,
    - if the Publisher implementation is able to emit an onError without requests,
    - if the Publisher is non-empty as this test expects a Publisher without items.
    Specified by:
    
    required_spec109_mayRejectCallsToSubscribeIfPublisherIsUnableOrUnwillingToServeThemRejectionMustTriggerOnErrorAfterOnSubscribe in interface PublisherVerificationRules
    
    Throws:
    
    java.lang.Throwable
  - required_spec109_mustIssueOnSubscribeForNonNullSubscriber
```
public void required_spec109_mustIssueOnSubscribeForNonNullSubscriber()
                                                               throws java.lang.Throwable
```
    Description copied from interface: PublisherVerificationRules
    Asks for an empty Publisher and verifies if onSubscribe signal was emitted before any other onNext, onError or onComplete signal.
    Verifies rule: 1.9
    Note that this test doesn't request anything, however, an onNext is not considered as a failure.
    If this test fails, the following could be checked within the Publisher implementation:
    - the TestEnvironment has large enough timeout specified in case the Publisher has some time-delay behavior,
    - the Publisher.subscribe(Subscriber) method has actual implementation,
    - in the Publisher.subscribe(Subscriber) method, if there is an upstream Publisher, that Publisher is actually subscribed to,
    - in the Publisher.subscribe(Subscriber) method, the Subscriber.onSubscribe is called as part of the preparation process (usually before subscribing to other Publishers).
    Specified by:
    
    required_spec109_mustIssueOnSubscribeForNonNullSubscriber in interface PublisherVerificationRules
    
    Throws:
    
    java.lang.Throwable
  - untested_spec110_rejectASubscriptionRequestIfTheSameSubscriberSubscribesTwice
```
public void untested_spec110_rejectASubscriptionRequestIfTheSameSubscriberSubscribesTwice()
                                                                                   throws java.lang.Throwable
```
    Description copied from interface: PublisherVerificationRules
    
    Currently, this test is skipped because enforcing rule §1.10 requires unlimited retention and reference-equal checks on all incoming Subscriber which is generally infeasible, plus reusing the same Subscriber instance is better detected (or ignored) inside Subscriber.onSubscribe when the method is called multiple times.
    Verifies rule: 1.10
    
    Specified by:
    
    untested_spec110_rejectASubscriptionRequestIfTheSameSubscriberSubscribesTwice in interface PublisherVerificationRules
    
    Throws:
    
    java.lang.Throwable
  - optional_spec111_maySupportMultiSubscribe
```
public void optional_spec111_maySupportMultiSubscribe()
                                               throws java.lang.Throwable
```
    Description copied from interface: PublisherVerificationRules
    
    Asks for a single-element Publisher and subscribes to it twice, without consuming with either Subscriber instance (i.e., no requests are issued).
    Verifies rule: 1.11
    The test is not executed if PublisherVerification.maxElementsFromPublisher() is less than 1.
    Note that this test ignores what signals the Publisher emits. Any exception thrown through non-regular means will indicate a skipped test.
    
    Specified by:
    
    optional_spec111_maySupportMultiSubscribe in interface PublisherVerificationRules
    
    Throws:
    
    java.lang.Throwable
  - optional_spec111_registeredSubscribersMustReceiveOnNextOrOnCompleteSignals
```
public void optional_spec111_registeredSubscribersMustReceiveOnNextOrOnCompleteSignals()
                                                                                throws java.lang.Throwable
```
    Description copied from interface: PublisherVerificationRules
    
    Asks for a single-element Publisher and subscribes to it twice. Each Subscriber requests for 1 element and checks if onNext or onComplete signals was received.
    Verifies rule: 1.11, and depends on valid implementation of rule 1.5 in order to verify this.
    The test is not executed if PublisherVerification.maxElementsFromPublisher() is less than 1.
    Any exception thrown through non-regular means will indicate a skipped test.
    
    Specified by:
    
    optional_spec111_registeredSubscribersMustReceiveOnNextOrOnCompleteSignals in interface PublisherVerificationRules
    
    Throws:
    
    java.lang.Throwable
  - optional_spec111_multicast_mustProduceTheSameElementsInTheSameSequenceToAllOfItsSubscribersWhenRequestingOneByOne
```
public void optional_spec111_multicast_mustProduceTheSameElementsInTheSameSequenceToAllOfItsSubscribersWhenRequestingOneByOne()
                                                                                                                       throws java.lang.Throwable
```
    Description copied from interface: PublisherVerificationRules
    Asks for a short Publisher (length 5), subscribes 3 Subscribers to it, requests with different patterns and checks if all 3 received the same events in the same order.
    Verifies rule: 1.11
    The test is not executed if PublisherVerification.maxElementsFromPublisher() is less than 5.
    The request pattern for the first Subscriber is (1, 1, 2, 1); for the second is (2, 3) and for the third is (3, 1, 1).
    Note that this test requires a Publisher that always emits the same signals to any Subscriber, regardless of when they subscribe and how they request elements. I.e., a "live" Publisher emitting the current time would not pass this test.
    Note that this test is optional and may appear skipped even if the behavior should be actually supported by the Publisher, see the skip message for an indication of this.
    If this test fails, the following could be checked within the Publisher implementation:
    - the TestEnvironment has large enough timeout specified in case the Publisher has some time-delay behavior,
    - make sure the PublisherVerificationRules.required_createPublisher1MustProduceAStreamOfExactly1Element() and PublisherVerificationRules.required_createPublisher3MustProduceAStreamOfExactly3Elements() tests pass,
    - if the Publisher implementation considers the cumulative request amount it receives,
    - if the Publisher doesn't lose any request() signal and the state transition from idle -> emitting or emitting -> keep emitting works properly.
    Specified by:
    
    optional_spec111_multicast_mustProduceTheSameElementsInTheSameSequenceToAllOfItsSubscribersWhenRequestingOneByOne in interface PublisherVerificationRules
    
    Throws:
    
    java.lang.Throwable
  - optional_spec111_multicast_mustProduceTheSameElementsInTheSameSequenceToAllOfItsSubscribersWhenRequestingManyUpfront
```
public void optional_spec111_multicast_mustProduceTheSameElementsInTheSameSequenceToAllOfItsSubscribersWhenRequestingManyUpfront()
                                                                                                                          throws java.lang.Throwable
```
    Description copied from interface: PublisherVerificationRules
    Asks for a short Publisher (length 3), subscribes 3 Subscribers to it, requests more than the length items upfront with each and verifies they all received the same items in the same order (but does not verify they all complete).
    Verifies rule: 1.11
    The test is not executed if PublisherVerification.maxElementsFromPublisher() is less than 3.
    Note that this test requires a Publisher that always emits the same signals to any Subscriber, regardless of when they subscribe and how they request elements. I.e., a "live" Publisher emitting the current time would not pass this test.
    Note that this test is optional and may appear skipped even if the behavior should be actually supported by the Publisher, see the skip message for an indication of this.
    If this test fails, the following could be checked within the Publisher implementation:
    - the TestEnvironment has large enough timeout specified in case the Publisher has some time-delay behavior,
    - make sure the PublisherVerificationRules.required_createPublisher1MustProduceAStreamOfExactly1Element() and PublisherVerificationRules.required_createPublisher3MustProduceAStreamOfExactly3Elements() tests pass,
    - if the Publisher implementation considers the cumulative request amount it receives,
    - if the Publisher doesn't lose any request() signal and the state transition from idle -> emitting or emitting -> keep emitting works properly.
    Specified by:
    
    optional_spec111_multicast_mustProduceTheSameElementsInTheSameSequenceToAllOfItsSubscribersWhenRequestingManyUpfront in interface PublisherVerificationRules
    
    Throws:
    
    java.lang.Throwable
  - optional_spec111_multicast_mustProduceTheSameElementsInTheSameSequenceToAllOfItsSubscribersWhenRequestingManyUpfrontAndCompleteAsExpected
```
public void optional_spec111_multicast_mustProduceTheSameElementsInTheSameSequenceToAllOfItsSubscribersWhenRequestingManyUpfrontAndCompleteAsExpected()
                                                                                                                                               throws java.lang.Throwable
```
    Description copied from interface: PublisherVerificationRules
    Asks for a short Publisher (length 3), subscribes 3 Subscribers to it, requests more than the length items upfront with each and verifies they all received the same items in the same order followed by an onComplete signal.
    Verifies rule: 1.11
    The test is not executed if PublisherVerification.maxElementsFromPublisher() is less than 3.
    Note that this test requires a Publisher that always emits the same signals to any Subscriber, regardless of when they subscribe and how they request elements. I.e., a "live" Publisher emitting the current time would not pass this test.
    Note that this test is optional and may appear skipped even if the behavior should be actually supported by the Publisher, see the skip message for an indication of this.
    If this test fails, the following could be checked within the Publisher implementation:
    - the TestEnvironment has large enough timeout specified in case the Publisher has some time-delay behavior,
    - make sure the PublisherVerificationRules.required_createPublisher1MustProduceAStreamOfExactly1Element() and PublisherVerificationRules.required_createPublisher3MustProduceAStreamOfExactly3Elements() tests pass,
    - if the Publisher implementation considers the cumulative request amount it receives,
    - if the Publisher doesn't lose any request() signal and the state transition from idle -> emitting or emitting -> keep emitting works properly.
    Specified by:
    
    optional_spec111_multicast_mustProduceTheSameElementsInTheSameSequenceToAllOfItsSubscribersWhenRequestingManyUpfrontAndCompleteAsExpected in interface PublisherVerificationRules
    
    Throws:
    
    java.lang.Throwable
  - required_spec302_mustAllowSynchronousRequestCallsFromOnNextAndOnSubscribe
```
public void required_spec302_mustAllowSynchronousRequestCallsFromOnNextAndOnSubscribe()
                                                                               throws java.lang.Throwable
```
    Description copied from interface: PublisherVerificationRules
    Asks for a short Publisher (length 6), requests several times from within onSubscribe and then requests one-by-one from onNext.
    Verifies rule: 3.2
    The test is not executed if PublisherVerification.maxElementsFromPublisher() is less than 6.
    The request pattern is 3 x 1 from within onSubscribe and one from within each onNext invocation.
    The test consumes the Publisher but otherwise doesn't verify the Publisher completes (however, it checks for errors).
    If this test fails, the following could be checked within the Publisher implementation:
    - the TestEnvironment has large enough timeout specified in case the Publisher has some time-delay behavior,
    - make sure the PublisherVerificationRules.required_createPublisher1MustProduceAStreamOfExactly1Element() and PublisherVerificationRules.required_createPublisher3MustProduceAStreamOfExactly3Elements() tests pass,
    - if the Publisher implementation considers the cumulative request amount it receives,
    - if the Publisher doesn't lose any request() signal and the state transition from idle -> emitting or emitting -> keep emitting works properly.
    Specified by:
    
    required_spec302_mustAllowSynchronousRequestCallsFromOnNextAndOnSubscribe in interface PublisherVerificationRules
    
    Throws:
    
    java.lang.Throwable
  - required_spec303_mustNotAllowUnboundedRecursion
```
public void required_spec303_mustNotAllowUnboundedRecursion()
                                                     throws java.lang.Throwable
```
    Description copied from interface: PublisherVerificationRules
    Asks for a Publisher with length equal to the value returned by PublisherVerificationRules.required_validate_boundedDepthOfOnNextAndRequestRecursion() plus 1, calls request(1) externally and then from within onNext and checks if the stack depth did not increase beyond the amount permitted by PublisherVerificationRules.required_validate_boundedDepthOfOnNextAndRequestRecursion().
    Verifies rule: 3.3
    The test is not executed if PublisherVerification.maxElementsFromPublisher() is less than PublisherVerificationRules.required_validate_boundedDepthOfOnNextAndRequestRecursion() plus 1.
    If this test fails, the following could be checked within the Publisher implementation:
    - the TestEnvironment has large enough timeout specified in case the Publisher has some time-delay behavior,
    - make sure the PublisherVerificationRules.required_createPublisher1MustProduceAStreamOfExactly1Element() and PublisherVerificationRules.required_createPublisher3MustProduceAStreamOfExactly3Elements() tests pass,
    - the implementation doesn't allow unbounded recursion when request() is called from within onNext, i.e., the lack of reentrant-safe state machine around the request amount (such as a for loop with a bound on the parameter n that calls onNext).
    Specified by:
    
    required_spec303_mustNotAllowUnboundedRecursion in interface PublisherVerificationRules
    
    Throws:
    
    java.lang.Throwable
  - untested_spec304_requestShouldNotPerformHeavyComputations
```
public void untested_spec304_requestShouldNotPerformHeavyComputations()
                                                               throws java.lang.Exception
```
    Description copied from interface: PublisherVerificationRules
    
    Currently, this test is skipped because a request could enter into a synchronous computation via onNext legally and otherwise there is no common agreement how to detect such heavy computation reliably.
    Verifies rule: 3.4
    
    Specified by:
    
    untested_spec304_requestShouldNotPerformHeavyComputations in interface PublisherVerificationRules
    
    Throws:
    
    java.lang.Exception
  - untested_spec305_cancelMustNotSynchronouslyPerformHeavyComputation
```
public void untested_spec305_cancelMustNotSynchronouslyPerformHeavyComputation()
                                                                        throws java.lang.Exception
```
    Description copied from interface: PublisherVerificationRules
    
    Currently, this test is skipped because there is no reliable agreed upon way to detect a heavy computation.
    Verifies rule: 3.5
    
    Specified by:
    
    untested_spec305_cancelMustNotSynchronouslyPerformHeavyComputation in interface PublisherVerificationRules
    
    Throws:
    
    java.lang.Exception
  - required_spec306_afterSubscriptionIsCancelledRequestMustBeNops
```
public void required_spec306_afterSubscriptionIsCancelledRequestMustBeNops()
                                                                    throws java.lang.Throwable
```
    Description copied from interface: PublisherVerificationRules
    Asks for a short Publisher (length 3) and verifies that cancelling without requesting anything, then requesting items should result in no signals to be emitted.
    Verifies rule: 3.6
    The test is not executed if PublisherVerification.maxElementsFromPublisher() is less than 3.
    The post-cancellation request pattern is (1, 1, 1).
    If this test fails, the following could be checked within the Publisher implementation:
    - the TestEnvironment has large enough timeout specified in case the Publisher has some time-delay behavior,
    - make sure the PublisherVerificationRules.required_createPublisher1MustProduceAStreamOfExactly1Element() and PublisherVerificationRules.required_createPublisher3MustProduceAStreamOfExactly3Elements() tests pass,
    - the cancellation indicator flag is properly persisted (may require volatile) and checked as part of the signal emission process.
    Specified by:
    
    required_spec306_afterSubscriptionIsCancelledRequestMustBeNops in interface PublisherVerificationRules
    
    Throws:
    
    java.lang.Throwable
  - required_spec307_afterSubscriptionIsCancelledAdditionalCancelationsMustBeNops
```
public void required_spec307_afterSubscriptionIsCancelledAdditionalCancelationsMustBeNops()
                                                                                   throws java.lang.Throwable
```
    Description copied from interface: PublisherVerificationRules
    Asks for a single-element Publisher and verifies that without requesting anything, cancelling the sequence multiple times should result in no signals to be emitted and should result in an thrown exception.
    Verifies rule: 3.7
    The test is not executed if PublisherVerification.maxElementsFromPublisher() is less than 1.
    If this test fails, the following could be checked within the Publisher implementation:
    - the TestEnvironment has large enough timeout specified in case the Publisher has some time-delay behavior,
    - make sure the PublisherVerificationRules.required_createPublisher1MustProduceAStreamOfExactly1Element() and PublisherVerificationRules.required_createPublisher3MustProduceAStreamOfExactly3Elements() tests pass,
    - the cancellation indicator flag is properly persisted (may require volatile) and checked as part of the signal emission process.
    Specified by:
    
    required_spec307_afterSubscriptionIsCancelledAdditionalCancelationsMustBeNops in interface PublisherVerificationRules
    
    Throws:
    
    java.lang.Throwable
  - required_spec309_requestZeroMustSignalIllegalArgumentException
```
public void required_spec309_requestZeroMustSignalIllegalArgumentException()
                                                                    throws java.lang.Throwable
```
    Description copied from interface: PublisherVerificationRules
    Asks for a short Publisher (length 10) and issues a request(0) which should trigger an onError call with an IllegalArgumentException.
    Verifies rule: 3.9
    The test is not executed if PublisherVerification.maxElementsFromPublisher() is less than 10.
    Note that this test expects the IllegalArgumentException being signalled through onError, not by throwing from request() (which is also forbidden) or signalling the error by any other means (i.e., through the Thread.currentThread().getUncaughtExceptionHandler() for example).
    Note also that requesting and emission may happen concurrently and honoring this rule may require extra coordination within the Publisher.
    If this test fails, the following could be checked within the Publisher implementation:
    - the TestEnvironment has large enough timeout specified in case the Publisher has some time-delay behavior,
    - make sure the PublisherVerificationRules.required_createPublisher1MustProduceAStreamOfExactly1Element() and PublisherVerificationRules.required_createPublisher3MustProduceAStreamOfExactly3Elements() tests pass,
    - the Publisher can emit an onError in this particular case, even if there was no prior and legal request call and even if the Publisher would like to emit items first before emitting an onError in general.
    Specified by:
    
    required_spec309_requestZeroMustSignalIllegalArgumentException in interface PublisherVerificationRules
    
    Throws:
    
    java.lang.Throwable
  - required_spec309_requestNegativeNumberMustSignalIllegalArgumentException
```
public void required_spec309_requestNegativeNumberMustSignalIllegalArgumentException()
                                                                              throws java.lang.Throwable
```
    Description copied from interface: PublisherVerificationRules
    Asks for a short Publisher (length 10) and issues a random, negative request() call which should trigger an onError call with an IllegalArgumentException.
    Verifies rule: 3.9
    The test is not executed if PublisherVerification.maxElementsFromPublisher() is less than 10.
    Note that this test expects the IllegalArgumentException being signalled through onError, not by throwing from request() (which is also forbidden) or signalling the error by any other means (i.e., through the Thread.currentThread().getUncaughtExceptionHandler() for example).
    Note also that requesting and emission may happen concurrently and honoring this rule may require extra coordination within the Publisher.
    If this test fails, the following could be checked within the Publisher implementation:
    - the TestEnvironment has large enough timeout specified in case the Publisher has some time-delay behavior,
    - make sure the PublisherVerificationRules.required_createPublisher1MustProduceAStreamOfExactly1Element() and PublisherVerificationRules.required_createPublisher3MustProduceAStreamOfExactly3Elements() tests pass,
    - the Publisher can emit an onError in this particular case, even if there was no prior and legal request call and even if the Publisher would like to emit items first before emitting an onError in general.
    Specified by:
    
    required_spec309_requestNegativeNumberMustSignalIllegalArgumentException in interface PublisherVerificationRules
    
    Throws:
    
    java.lang.Throwable
  - optional_spec309_requestNegativeNumberMaySignalIllegalArgumentExceptionWithSpecificMessage
```
public void optional_spec309_requestNegativeNumberMaySignalIllegalArgumentExceptionWithSpecificMessage()
                                                                                                throws java.lang.Throwable
```
    Description copied from interface: PublisherVerificationRules
    Asks for a short Publisher (length 10) and issues a random, negative request() call which should trigger an onError call with an IllegalArgumentException.
    Verifies rule: 3.9
    The test is not executed if PublisherVerification.maxElementsFromPublisher() is less than 10.
    Note that this test expects the IllegalArgumentException being signalled through onError, not by throwing from request() (which is also forbidden) or signalling the error by any other means (i.e., through the Thread.currentThread().getUncaughtExceptionHandler() for example).
    Note also that requesting and emission may happen concurrently and honoring this rule may require extra coordination within the Publisher.
    If this test fails, the following could be checked within the Publisher implementation:
    - the TestEnvironment has large enough timeout specified in case the Publisher has some time-delay behavior,
    - make sure the PublisherVerificationRules.required_createPublisher1MustProduceAStreamOfExactly1Element() and PublisherVerificationRules.required_createPublisher3MustProduceAStreamOfExactly3Elements() tests pass,
    - the Publisher can emit an onError in this particular case, even if there was no prior and legal request call and even if the Publisher would like to emit items first before emitting an onError in general.
    Specified by:
    
    optional_spec309_requestNegativeNumberMaySignalIllegalArgumentExceptionWithSpecificMessage in interface PublisherVerificationRules
    
    Throws:
    
    java.lang.Throwable
  - required_spec312_cancelMustMakeThePublisherToEventuallyStopSignaling
```
public void required_spec312_cancelMustMakeThePublisherToEventuallyStopSignaling()
                                                                          throws java.lang.Throwable
```
    Description copied from interface: PublisherVerificationRules
    Asks for a short Publisher (length 20), requests some items (less than the length), consumes one item then cancels the sequence and verifies the publisher emitted at most the requested amount and stopped emitting (or terminated).
    Verifies rule: 3.12
    The test is not executed if PublisherVerification.maxElementsFromPublisher() is less than 20.
    If this test fails, the following could be checked within the Publisher implementation:
    - the TestEnvironment has large enough timeout specified in case the Publisher has some time-delay behavior,
    - make sure the PublisherVerificationRules.required_createPublisher1MustProduceAStreamOfExactly1Element() and PublisherVerificationRules.required_createPublisher3MustProduceAStreamOfExactly3Elements() tests pass,
    - the cancellation indicator flag is properly persisted (may require volatile) and checked as part of the signal emission process.
    Specified by:
    
    required_spec312_cancelMustMakeThePublisherToEventuallyStopSignaling in interface PublisherVerificationRules
    
    Throws:
    
    java.lang.Throwable
  - required_spec313_cancelMustMakeThePublisherEventuallyDropAllReferencesToTheSubscriber
```
public void required_spec313_cancelMustMakeThePublisherEventuallyDropAllReferencesToTheSubscriber()
                                                                                           throws java.lang.Throwable
```
    Description copied from interface: PublisherVerificationRules
    Asks for a short Publisher (length 3) requests and consumes one element from it, cancels the Subscription , calls System.gc() and then checks if all references to the test Subscriber has been dropped (by checking the WeakReference has been emptied).
    Verifies rule: 3.13
    The test is not executed if PublisherVerification.maxElementsFromPublisher() is less than 3.
    If this test fails, the following could be checked within the Publisher implementation:
    - the TestEnvironment has large enough timeout specified in case the Publisher has some time-delay behavior,
    - make sure the PublisherVerificationRules.required_createPublisher1MustProduceAStreamOfExactly1Element() and PublisherVerificationRules.required_createPublisher3MustProduceAStreamOfExactly3Elements() tests pass,
    - the cancellation indicator flag is properly persisted (may require volatile) and checked as part of the signal emission process.
    - the Publisher stores the Subscriber reference somewhere which is then not cleaned up when the Subscriber is cancelled. Note that this may happen on many code paths in a Publisher, for example in an emission loop that terminates because of the cancel signal or because reaching a terminal state. Note also that eagerly nulling Subscriber references may not be necessary for this test to pass in case there is a self-contained chain of them (i.e., Publisher.subscribe() creates a chain of fresh Subscriber instances where each of them only references their downstream Subscriber thus the chain can get GC'd when the reference to the final Subscriber is dropped).
    Specified by:
    
    required_spec313_cancelMustMakeThePublisherEventuallyDropAllReferencesToTheSubscriber in interface PublisherVerificationRules
    
    Throws:
    
    java.lang.Throwable
  - required_spec317_mustSupportAPendingElementCountUpToLongMaxValue
```
public void required_spec317_mustSupportAPendingElementCountUpToLongMaxValue()
                                                                      throws java.lang.Throwable
```
    Description copied from interface: PublisherVerificationRules
    Asks for a short Publisher (length 3) and requests Long.MAX_VALUE from it, verifying that the Publisher emits all of its items and completes normally and does not keep spinning attempting to fulfill the Long.MAX_VALUE demand by some means.
    Verifies rule: 3.17
    The test is not executed if PublisherVerification.maxElementsFromPublisher() is less than 3.
    If this test fails, the following could be checked within the Publisher implementation:
    - the TestEnvironment has large enough timeout specified in case the Publisher has some time-delay behavior,
    - make sure the PublisherVerificationRules.required_createPublisher1MustProduceAStreamOfExactly1Element() and PublisherVerificationRules.required_createPublisher3MustProduceAStreamOfExactly3Elements() tests pass,
    - if the Publisher implementation considers the cumulative request amount it receives,
    - if the Publisher doesn't lose any request() signal and the state transition from idle -> emitting or emitting -> keep emitting works properly.
    Specified by:
    
    required_spec317_mustSupportAPendingElementCountUpToLongMaxValue in interface PublisherVerificationRules
    
    Throws:
    
    java.lang.Throwable
  - required_spec317_mustSupportACumulativePendingElementCountUpToLongMaxValue
```
public void required_spec317_mustSupportACumulativePendingElementCountUpToLongMaxValue()
                                                                                throws java.lang.Throwable
```
    Description copied from interface: PublisherVerificationRules
    Asks for a short Publisher (length 3) and requests Long.MAX_VALUE from it in total (split across two Long.MAX_VALUE / 2 and one request(1)), verifying that the Publisher emits all of its items and completes normally.
    Verifies rule: 3.17
    The test is not executed if PublisherVerification.maxElementsFromPublisher() is less than 3.
    If this test fails, the following could be checked within the Publisher implementation:
    - the TestEnvironment has large enough timeout specified in case the Publisher has some time-delay behavior,
    - make sure the PublisherVerificationRules.required_createPublisher1MustProduceAStreamOfExactly1Element() and PublisherVerificationRules.required_createPublisher3MustProduceAStreamOfExactly3Elements() tests pass,
    - if the Publisher implementation considers the cumulative request amount it receives,
    - if the Publisher implements adding individual request amounts together properly (not overflowing into zero or negative pending request amounts) or not properly deducing the number of emitted items from the pending amount,
    - if the Publisher doesn't lose any request() signal and the state transition from idle -> emitting or emitting -> keep emitting works properly.
    Specified by:
    
    required_spec317_mustSupportACumulativePendingElementCountUpToLongMaxValue in interface PublisherVerificationRules
    
    Throws:
    
    java.lang.Throwable
  - required_spec317_mustNotSignalOnErrorWhenPendingAboveLongMaxValue
```
public void required_spec317_mustNotSignalOnErrorWhenPendingAboveLongMaxValue()
                                                                       throws java.lang.Throwable
```
    Description copied from interface: PublisherVerificationRules
    Asks for a very long Publisher (up to Integer.MAX_VALUE), requests Long.MAX_VALUE - 1 after each received item and expects no failure due to a potential overflow in the pending emission count while consuming 10 items and cancelling the sequence.
    Verifies rule: 3.17
    The test is not executed if PublisherVerification.maxElementsFromPublisher() is less than Integer.MAX_VALUE.
    The request pattern is one request(1) upfront and ten request(Long.MAX_VALUE - 1) after.
    If this test fails, the following could be checked within the Publisher implementation:
    - the TestEnvironment has large enough timeout specified in case the Publisher has some time-delay behavior,
    - make sure the PublisherVerificationRules.required_createPublisher1MustProduceAStreamOfExactly1Element() and PublisherVerificationRules.required_createPublisher3MustProduceAStreamOfExactly3Elements() tests pass,
    - if the Publisher implementation considers the cumulative request amount it receives,
    - if the Publisher implements adding individual request amounts together properly (not overflowing into zero or negative pending request amounts) or not properly deducing the number of emitted items from the pending amount,
    - if the Publisher doesn't lose any request() signal and the state transition from idle -> emitting or emitting -> keep emitting works properly.
    Specified by:
    
    required_spec317_mustNotSignalOnErrorWhenPendingAboveLongMaxValue in interface PublisherVerificationRules
    
    Throws:
    
    java.lang.Throwable
  - required_spec104_mustCallOnErrorOnAllItsSubscribersIfItEncountersANonRecoverableError
```
public void required_spec104_mustCallOnErrorOnAllItsSubscribersIfItEncountersANonRecoverableError()
                                                                                           throws java.lang.Throwable
```
    Asks for a Processor that supports at least 2 Subscribers at once and checks if two Subscribers receive the same items and a terminal Exception.
    If the Processor requests and/or emits items only when all of its Subscribers have requested, override doesCoordinatedEmission() and return true to indicate this property.
    Verifies rule: 1.4 with multiple Subscribers.
    The test is not executed if maxSupportedSubscribers() is less than 2.
    If this test fails, the following could be checked within the Processor implementation:
    - The TestEnvironment has large enough timeout specified in case the Processor has some time-delay behavior.
    - The Processor is able to fulfill requests of its Subscribers independently of each other's requests or else override doesCoordinatedEmission() and return true to indicate the test Subscribers both have to request first.
    Throws:
    
    java.lang.Throwable
  - createSubscriber
```
public org.reactivestreams.Subscriber<T> createSubscriber(SubscriberWhiteboxVerification.WhiteboxSubscriberProbe<T> probe)
```
  - mustImmediatelyPassOnOnErrorEventsReceivedFromItsUpstreamToItsDownstream
```
public void mustImmediatelyPassOnOnErrorEventsReceivedFromItsUpstreamToItsDownstream()
                                                                              throws java.lang.Exception
```
    Throws:
    
    java.lang.Exception
  - required_exerciseWhiteboxHappyPath
```
public void required_exerciseWhiteboxHappyPath()
                                        throws java.lang.Throwable
```
    Specified by:
    
    required_exerciseWhiteboxHappyPath in interface SubscriberWhiteboxVerificationRules
    
    Throws:
    
    java.lang.Throwable
  - required_spec201_mustSignalDemandViaSubscriptionRequest
```
public void required_spec201_mustSignalDemandViaSubscriptionRequest()
                                                             throws java.lang.Throwable
```
    Specified by:
    
    required_spec201_mustSignalDemandViaSubscriptionRequest in interface SubscriberWhiteboxVerificationRules
    
    Throws:
    
    java.lang.Throwable
  - untested_spec202_shouldAsynchronouslyDispatch
```
public void untested_spec202_shouldAsynchronouslyDispatch()
                                                   throws java.lang.Exception
```
    Specified by:
    
    untested_spec202_shouldAsynchronouslyDispatch in interface SubscriberWhiteboxVerificationRules
    
    Throws:
    
    java.lang.Exception
  - required_spec203_mustNotCallMethodsOnSubscriptionOrPublisherInOnComplete
```
public void required_spec203_mustNotCallMethodsOnSubscriptionOrPublisherInOnComplete()
                                                                              throws java.lang.Throwable
```
    Specified by:
    
    required_spec203_mustNotCallMethodsOnSubscriptionOrPublisherInOnComplete in interface SubscriberWhiteboxVerificationRules
    
    Throws:
    
    java.lang.Throwable
  - required_spec203_mustNotCallMethodsOnSubscriptionOrPublisherInOnError
```
public void required_spec203_mustNotCallMethodsOnSubscriptionOrPublisherInOnError()
                                                                           throws java.lang.Throwable
```
    Specified by:
    
    required_spec203_mustNotCallMethodsOnSubscriptionOrPublisherInOnError in interface SubscriberWhiteboxVerificationRules
    
    Throws:
    
    java.lang.Throwable
  - untested_spec204_mustConsiderTheSubscriptionAsCancelledInAfterRecievingOnCompleteOrOnError
```
public void untested_spec204_mustConsiderTheSubscriptionAsCancelledInAfterRecievingOnCompleteOrOnError()
                                                                                                throws java.lang.Exception
```
    Specified by:
    
    untested_spec204_mustConsiderTheSubscriptionAsCancelledInAfterRecievingOnCompleteOrOnError in interface SubscriberWhiteboxVerificationRules
    
    Throws:
    
    java.lang.Exception
  - required_spec205_mustCallSubscriptionCancelIfItAlreadyHasAnSubscriptionAndReceivesAnotherOnSubscribeSignal
```
public void required_spec205_mustCallSubscriptionCancelIfItAlreadyHasAnSubscriptionAndReceivesAnotherOnSubscribeSignal()
                                                                                                                throws java.lang.Throwable
```
    Specified by:
    
    required_spec205_mustCallSubscriptionCancelIfItAlreadyHasAnSubscriptionAndReceivesAnotherOnSubscribeSignal in interface SubscriberWhiteboxVerificationRules
    
    Throws:
    
    java.lang.Throwable
  - untested_spec206_mustCallSubscriptionCancelIfItIsNoLongerValid
```
public void untested_spec206_mustCallSubscriptionCancelIfItIsNoLongerValid()
                                                                    throws java.lang.Exception
```
    Specified by:
    
    untested_spec206_mustCallSubscriptionCancelIfItIsNoLongerValid in interface SubscriberWhiteboxVerificationRules
    
    Throws:
    
    java.lang.Exception
  - untested_spec207_mustEnsureAllCallsOnItsSubscriptionTakePlaceFromTheSameThreadOrTakeCareOfSynchronization
```
public void untested_spec207_mustEnsureAllCallsOnItsSubscriptionTakePlaceFromTheSameThreadOrTakeCareOfSynchronization()
                                                                                                               throws java.lang.Exception
```
    Specified by:
    
    untested_spec207_mustEnsureAllCallsOnItsSubscriptionTakePlaceFromTheSameThreadOrTakeCareOfSynchronization in interface SubscriberWhiteboxVerificationRules
    
    Throws:
    
    java.lang.Exception
  - required_spec208_mustBePreparedToReceiveOnNextSignalsAfterHavingCalledSubscriptionCancel
```
public void required_spec208_mustBePreparedToReceiveOnNextSignalsAfterHavingCalledSubscriptionCancel()
                                                                                              throws java.lang.Throwable
```
    Specified by:
    
    required_spec208_mustBePreparedToReceiveOnNextSignalsAfterHavingCalledSubscriptionCancel in interface SubscriberWhiteboxVerificationRules
    
    Throws:
    
    java.lang.Throwable
  - required_spec209_mustBePreparedToReceiveAnOnCompleteSignalWithPrecedingRequestCall
```
public void required_spec209_mustBePreparedToReceiveAnOnCompleteSignalWithPrecedingRequestCall()
                                                                                        throws java.lang.Throwable
```
    Specified by:
    
    required_spec209_mustBePreparedToReceiveAnOnCompleteSignalWithPrecedingRequestCall in interface SubscriberWhiteboxVerificationRules
    
    Throws:
    
    java.lang.Throwable
  - required_spec209_mustBePreparedToReceiveAnOnCompleteSignalWithoutPrecedingRequestCall
```
public void required_spec209_mustBePreparedToReceiveAnOnCompleteSignalWithoutPrecedingRequestCall()
                                                                                           throws java.lang.Throwable
```
    Specified by:
    
    required_spec209_mustBePreparedToReceiveAnOnCompleteSignalWithoutPrecedingRequestCall in interface SubscriberWhiteboxVerificationRules
    
    Throws:
    
    java.lang.Throwable
  - required_spec210_mustBePreparedToReceiveAnOnErrorSignalWithPrecedingRequestCall
```
public void required_spec210_mustBePreparedToReceiveAnOnErrorSignalWithPrecedingRequestCall()
                                                                                     throws java.lang.Throwable
```
    Specified by:
    
    required_spec210_mustBePreparedToReceiveAnOnErrorSignalWithPrecedingRequestCall in interface SubscriberWhiteboxVerificationRules
    
    Throws:
    
    java.lang.Throwable
  - required_spec210_mustBePreparedToReceiveAnOnErrorSignalWithoutPrecedingRequestCall
```
public void required_spec210_mustBePreparedToReceiveAnOnErrorSignalWithoutPrecedingRequestCall()
                                                                                        throws java.lang.Throwable
```
    Specified by:
    
    required_spec210_mustBePreparedToReceiveAnOnErrorSignalWithoutPrecedingRequestCall in interface SubscriberWhiteboxVerificationRules
    
    Throws:
    
    java.lang.Throwable
  - untested_spec211_mustMakeSureThatAllCallsOnItsMethodsHappenBeforeTheProcessingOfTheRespectiveEvents
```
public void untested_spec211_mustMakeSureThatAllCallsOnItsMethodsHappenBeforeTheProcessingOfTheRespectiveEvents()
                                                                                                         throws java.lang.Exception
```
    Specified by:
    
    untested_spec211_mustMakeSureThatAllCallsOnItsMethodsHappenBeforeTheProcessingOfTheRespectiveEvents in interface SubscriberWhiteboxVerificationRules
    
    Throws:
    
    java.lang.Exception
  - untested_spec212_mustNotCallOnSubscribeMoreThanOnceBasedOnObjectEquality_specViolation
```
public void untested_spec212_mustNotCallOnSubscribeMoreThanOnceBasedOnObjectEquality_specViolation()
                                                                                            throws java.lang.Throwable
```
    Specified by:
    
    untested_spec212_mustNotCallOnSubscribeMoreThanOnceBasedOnObjectEquality_specViolation in interface SubscriberWhiteboxVerificationRules
    
    Throws:
    
    java.lang.Throwable
  - untested_spec213_failingOnSignalInvocation
```
public void untested_spec213_failingOnSignalInvocation()
                                                throws java.lang.Exception
```
    Specified by:
    
    untested_spec213_failingOnSignalInvocation in interface SubscriberWhiteboxVerificationRules
    
    Throws:
    
    java.lang.Exception
  - required_spec213_onSubscribe_mustThrowNullPointerExceptionWhenParametersAreNull
```
public void required_spec213_onSubscribe_mustThrowNullPointerExceptionWhenParametersAreNull()
                                                                                     throws java.lang.Throwable
```
    Specified by:
    
    required_spec213_onSubscribe_mustThrowNullPointerExceptionWhenParametersAreNull in interface SubscriberWhiteboxVerificationRules
    
    Throws:
    
    java.lang.Throwable
  - required_spec213_onNext_mustThrowNullPointerExceptionWhenParametersAreNull
```
public void required_spec213_onNext_mustThrowNullPointerExceptionWhenParametersAreNull()
                                                                                throws java.lang.Throwable
```
    Specified by:
    
    required_spec213_onNext_mustThrowNullPointerExceptionWhenParametersAreNull in interface SubscriberWhiteboxVerificationRules
    
    Throws:
    
    java.lang.Throwable
  - required_spec213_onError_mustThrowNullPointerExceptionWhenParametersAreNull
```
public void required_spec213_onError_mustThrowNullPointerExceptionWhenParametersAreNull()
                                                                                 throws java.lang.Throwable
```
    Specified by:
    
    required_spec213_onError_mustThrowNullPointerExceptionWhenParametersAreNull in interface SubscriberWhiteboxVerificationRules
    
    Throws:
    
    java.lang.Throwable
  - untested_spec301_mustNotBeCalledOutsideSubscriberContext
```
public void untested_spec301_mustNotBeCalledOutsideSubscriberContext()
                                                              throws java.lang.Exception
```
    Specified by:
    
    untested_spec301_mustNotBeCalledOutsideSubscriberContext in interface SubscriberWhiteboxVerificationRules
    
    Throws:
    
    java.lang.Exception
  - required_spec308_requestMustRegisterGivenNumberElementsToBeProduced
```
public void required_spec308_requestMustRegisterGivenNumberElementsToBeProduced()
                                                                         throws java.lang.Throwable
```
    Specified by:
    
    required_spec308_requestMustRegisterGivenNumberElementsToBeProduced in interface SubscriberWhiteboxVerificationRules
    
    Throws:
    
    java.lang.Throwable
  - untested_spec310_requestMaySynchronouslyCallOnNextOnSubscriber
```
public void untested_spec310_requestMaySynchronouslyCallOnNextOnSubscriber()
                                                                    throws java.lang.Exception
```
    Specified by:
    
    untested_spec310_requestMaySynchronouslyCallOnNextOnSubscriber in interface SubscriberWhiteboxVerificationRules
    
    Throws:
    
    java.lang.Exception
  - untested_spec311_requestMaySynchronouslyCallOnCompleteOrOnError
```
public void untested_spec311_requestMaySynchronouslyCallOnCompleteOrOnError()
                                                                     throws java.lang.Exception
```
    Specified by:
    
    untested_spec311_requestMaySynchronouslyCallOnCompleteOrOnError in interface SubscriberWhiteboxVerificationRules
    
    Throws:
    
    java.lang.Exception
  - untested_spec314_cancelMayCauseThePublisherToShutdownIfNoOtherSubscriptionExists
```
public void untested_spec314_cancelMayCauseThePublisherToShutdownIfNoOtherSubscriptionExists()
                                                                                      throws java.lang.Exception
```
    Specified by:
    
    untested_spec314_cancelMayCauseThePublisherToShutdownIfNoOtherSubscriptionExists in interface SubscriberWhiteboxVerificationRules
    
    Throws:
    
    java.lang.Exception
  - untested_spec315_cancelMustNotThrowExceptionAndMustSignalOnError
```
public void untested_spec315_cancelMustNotThrowExceptionAndMustSignalOnError()
                                                                      throws java.lang.Exception
```
    Specified by:
    
    untested_spec315_cancelMustNotThrowExceptionAndMustSignalOnError in interface SubscriberWhiteboxVerificationRules
    
    Throws:
    
    java.lang.Exception
  - untested_spec316_requestMustNotThrowExceptionAndMustOnErrorTheSubscriber
```
public void untested_spec316_requestMustNotThrowExceptionAndMustOnErrorTheSubscriber()
                                                                              throws java.lang.Exception
```
    Specified by:
    
    untested_spec316_requestMustNotThrowExceptionAndMustOnErrorTheSubscriber in interface SubscriberWhiteboxVerificationRules
    
    Throws:
    
    java.lang.Exception
  - required_mustRequestFromUpstreamForElementsThatHaveBeenRequestedLongAgo
```
public void required_mustRequestFromUpstreamForElementsThatHaveBeenRequestedLongAgo()
                                                                             throws java.lang.Throwable
```
    Asks for a Processor that supports at least 2 Subscribers at once and checks requests from Subscribers will eventually lead to requests towards the upstream of the Processor.
    If the Processor requests and/or emits items only when all of its Subscribers have requested, override doesCoordinatedEmission() and return true to indicate this property.
    Verifies rule: 2.1 with multiple Subscribers.
    The test is not executed if maxSupportedSubscribers() is less than 2.
    If this test fails, the following could be checked within the Processor implementation:
    - The TestEnvironment has large enough timeout specified in case the Processor has some time-delay behavior.
    - The Processor is able to fulfill requests of its Subscribers independently of each other's requests or else override doesCoordinatedEmission() and return true to indicate the test Subscribers both have to request first.
    Throws:
    
    java.lang.Throwable
  - notVerified
```
public void notVerified()
```
  - notVerified
```
public void notVerified(java.lang.String message)
```
  - optionalMultipleSubscribersTest
```
public void optionalMultipleSubscribersTest(long requiredSubscribersSupport,
                                            Function<java.lang.Long,IdentityProcessorVerification.TestSetup> body)
                                     throws java.lang.Throwable
```
    Test for feature that REQUIRES multiple subscribers to be supported by Publisher.
    
    Throws:
    
    java.lang.Throwable

Class IdentityProcessorVerification<T>

Nested Class Summary

Constructor Summary

Method Summary

Methods inherited from class java.lang.Object

Methods inherited from class org.reactivestreams.tck.WithHelperPublisher

Constructor Detail

IdentityProcessorVerification

IdentityProcessorVerification

IdentityProcessorVerification

Method Detail

createIdentityProcessor

createFailedPublisher

maxElementsFromPublisher

boundedDepthOfOnNextAndRequestRecursion

skipStochasticTests

maxSupportedSubscribers

doesCoordinatedEmission

setUp

createPublisher

required_validate_maxElementsFromPublisher

required_validate_boundedDepthOfOnNextAndRequestRecursion

required_createPublisher1MustProduceAStreamOfExactly1Element

required_createPublisher3MustProduceAStreamOfExactly3Elements

required_spec101_subscriptionRequestMustResultInTheCorrectNumberOfProducedElements

required_spec102_maySignalLessThanRequestedAndTerminateSubscription

stochastic_spec103_mustSignalOnMethodsSequentially

optional_spec104_mustSignalOnErrorWhenFails

required_spec105_mustSignalOnCompleteWhenFiniteStreamTerminates

optional_spec105_emptyStreamMustTerminateBySignallingOnComplete

untested_spec106_mustConsiderSubscriptionCancelledAfterOnErrorOrOnCompleteHasBeenCalled

required_spec107_mustNotEmitFurtherSignalsOnceOnCompleteHasBeenSignalled

untested_spec107_mustNotEmitFurtherSignalsOnceOnErrorHasBeenSignalled

untested_spec108_possiblyCanceledSubscriptionShouldNotReceiveOnErrorOrOnCompleteSignals

untested_spec109_subscribeShouldNotThrowNonFatalThrowable

required_spec109_subscribeThrowNPEOnNullSubscriber

required_spec109_mayRejectCallsToSubscribeIfPublisherIsUnableOrUnwillingToServeThemRejectionMustTriggerOnErrorAfterOnSubscribe

required_spec109_mustIssueOnSubscribeForNonNullSubscriber

untested_spec110_rejectASubscriptionRequestIfTheSameSubscriberSubscribesTwice

optional_spec111_maySupportMultiSubscribe

optional_spec111_registeredSubscribersMustReceiveOnNextOrOnCompleteSignals

optional_spec111_multicast_mustProduceTheSameElementsInTheSameSequenceToAllOfItsSubscribersWhenRequestingOneByOne

optional_spec111_multicast_mustProduceTheSameElementsInTheSameSequenceToAllOfItsSubscribersWhenRequestingManyUpfront

optional_spec111_multicast_mustProduceTheSameElementsInTheSameSequenceToAllOfItsSubscribersWhenRequestingManyUpfrontAndCompleteAsExpected

required_spec302_mustAllowSynchronousRequestCallsFromOnNextAndOnSubscribe

required_spec303_mustNotAllowUnboundedRecursion

untested_spec304_requestShouldNotPerformHeavyComputations

untested_spec305_cancelMustNotSynchronouslyPerformHeavyComputation

required_spec306_afterSubscriptionIsCancelledRequestMustBeNops

required_spec307_afterSubscriptionIsCancelledAdditionalCancelationsMustBeNops

required_spec309_requestZeroMustSignalIllegalArgumentException

required_spec309_requestNegativeNumberMustSignalIllegalArgumentException

optional_spec309_requestNegativeNumberMaySignalIllegalArgumentExceptionWithSpecificMessage

required_spec312_cancelMustMakeThePublisherToEventuallyStopSignaling

required_spec313_cancelMustMakeThePublisherEventuallyDropAllReferencesToTheSubscriber

required_spec317_mustSupportAPendingElementCountUpToLongMaxValue

required_spec317_mustSupportACumulativePendingElementCountUpToLongMaxValue

required_spec317_mustNotSignalOnErrorWhenPendingAboveLongMaxValue

required_spec104_mustCallOnErrorOnAllItsSubscribersIfItEncountersANonRecoverableError

createSubscriber

mustImmediatelyPassOnOnErrorEventsReceivedFromItsUpstreamToItsDownstream

required_exerciseWhiteboxHappyPath

required_spec201_mustSignalDemandViaSubscriptionRequest

untested_spec202_shouldAsynchronouslyDispatch

required_spec203_mustNotCallMethodsOnSubscriptionOrPublisherInOnComplete

required_spec203_mustNotCallMethodsOnSubscriptionOrPublisherInOnError

untested_spec204_mustConsiderTheSubscriptionAsCancelledInAfterRecievingOnCompleteOrOnError

required_spec205_mustCallSubscriptionCancelIfItAlreadyHasAnSubscriptionAndReceivesAnotherOnSubscribeSignal

untested_spec206_mustCallSubscriptionCancelIfItIsNoLongerValid

untested_spec207_mustEnsureAllCallsOnItsSubscriptionTakePlaceFromTheSameThreadOrTakeCareOfSynchronization

required_spec208_mustBePreparedToReceiveOnNextSignalsAfterHavingCalledSubscriptionCancel

required_spec209_mustBePreparedToReceiveAnOnCompleteSignalWithPrecedingRequestCall

required_spec209_mustBePreparedToReceiveAnOnCompleteSignalWithoutPrecedingRequestCall

required_spec210_mustBePreparedToReceiveAnOnErrorSignalWithPrecedingRequestCall

required_spec210_mustBePreparedToReceiveAnOnErrorSignalWithoutPrecedingRequestCall

untested_spec211_mustMakeSureThatAllCallsOnItsMethodsHappenBeforeTheProcessingOfTheRespectiveEvents

untested_spec212_mustNotCallOnSubscribeMoreThanOnceBasedOnObjectEquality_specViolation

untested_spec213_failingOnSignalInvocation

required_spec213_onSubscribe_mustThrowNullPointerExceptionWhenParametersAreNull

required_spec213_onNext_mustThrowNullPointerExceptionWhenParametersAreNull