You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: tck/README.md
+107-15
Original file line number
Diff line number
Diff line change
@@ -51,7 +51,7 @@ Specification rule abides the following naming convention: `spec###_DESC` where:
51
51
```
52
52
53
53
The prefixes of the names of the test methods are used in order to signify the character of the test. For example, these are the kinds of prefixes you may find:
*`boundedDepthOfOnNextAndRequestRecursion` – which should only be overridden in case of synchronous Publishers. This number will be used to validate if a
175
172
`Subscription` actually solves the "unbounded recursion" problem (Rule 3.3).
176
173
174
+
### Timeout configuration
175
+
Publisher tests make use of two kinds of timeouts, one is the `defaultTimeoutMillis` which corresponds to all methods used
176
+
within the TCK which await for something to happen. The other timeout is `publisherReferenceGCTimeoutMillis` which is only used in order to verify
177
+
[Rule 3.13](https://github.com/reactive-streams/reactive-streams#3.13) which defines that subscriber references MUST be dropped
178
+
by the Publisher.
179
+
180
+
In order to configure these timeouts (for example when running on a slow continious integtation machine), you can either:
181
+
182
+
**Use env variables** to set these timeouts, in which case the you can just:
Note that explicitly passed in values take precedence over values provided by the environment
206
+
177
207
## Subscriber Verification
178
208
179
209
Subscriber rules Verification is split up into two files (styles) of tests.
180
210
181
211
The Blackbox Verification tests do not require the implementation under test to be modified at all, yet they are *not* able to verify most rules. In Whitebox Verification, more control over `request()` calls etc. is required in order to validate rules more precisely.
182
212
213
+
### createElement and Helper Publisher implementations
214
+
Since testing a `Subscriber` is not possible without a corresponding `Publisher` the TCK Subscriber Verifications
215
+
both provide a default "*helper publisher*" to drive its test and also alow to replace this Publisher with a custom implementation.
216
+
The helper publisher is an asynchronous publisher by default - meaning that your subscriber can not blindly assume single threaded execution.
217
+
218
+
While the `Publisher` implementation is provided, creating the signal elements is not – this is because a given Subscriber
219
+
may for example only work with `HashedMessage` or some other specific kind of signal. The TCK is unable to generate such
220
+
special messages automatically, so we provide the `T createElement(Integer id)` method to be implemented as part of
221
+
Subscriber Verifications which should take the given ID and return an element of type `T` (where `T` is the type of
222
+
elements flowing into the `Subscriber<T>`, as known thanks to `... extends WhiteboxSubscriberVerification<T>`) representing
223
+
an element of the stream that will be passed on to the Subscriber.
224
+
225
+
The simplest valid implemenation is to return the incoming `id`*as the element* in a verification using `Integer`s as element types:
Note that hard-coded values *take precedence* over environment set values (!).
386
+
387
+
296
388
## Subscription Verification
297
389
298
390
Please note that while `Subscription` does **not** have it's own test class, it's rules are validated inside of the `Publisher` and `Subscriber` tests – depending if the Rule demands specific action to be taken by the publishing, or subscribing side of the subscription contract.
0 commit comments