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
+8-11Lines changed: 8 additions & 11 deletions
Original file line number
Diff line number
Diff line change
@@ -87,10 +87,8 @@ Usually this means that this test case can yield false positives ("be green") ev
87
87
88
88
<aname="type-untested"></a>
89
89
The `untested_` means that the test case is not implemented, either because it is inherently hard to verify (e.g. Rules which use
90
-
the wording "*SHOULD consider X as Y*") or have not been implemented yet (though we hope we have implemented all we
91
-
could!). Such tests will show up in your test runs as `SKIPPED`, with a message pointing out that the TCK is unable to
92
-
validate this Rule. We would be delighted if you can figure out a way to deterministically test Rules, which have been
93
-
marked with this prefix – pull requests are very welcome!
90
+
the wording "*SHOULD consider X as Y*"). Such tests will show up in your test runs as `SKIPPED`, with a message pointing out that the TCK is unable to validate this Rule. If you figure out a way to deterministically test Rules which have been
91
+
marked with this prefix – pull requests are encouraged!
94
92
95
93
### Test isolation
96
94
@@ -200,12 +198,11 @@ public class RangePublisherTest extends PublisherVerification<Integer> {
200
198
201
199
Notable configuration options include:
202
200
203
-
*`maxElementsFromPublisher` – which should only be overridden in case the Publisher under test is not able to provide
204
-
arbitrary length streams, e.g. it's wrapping a `Future<T>` and thus can only publish up to 1 element. In such case you
205
-
should return `1` from this method. It will cause all tests which require more elements in order to validate a certain
201
+
*`maxElementsFromPublisher` – must be overridden in case the Publisher being tested is of bounded length, e.g. it's wrapping a `Future<T>` and thus can only publish up to 1 element, in which case you
202
+
would return `1` from this method. It will cause all tests which require more elements in order to validate a certain
206
203
Rule to be skipped,
207
-
*`boundedDepthOfOnNextAndRequestRecursion` – which should only be overridden in case of synchronous Publishers.
208
-
This number will be used to validate if a `Subscription`actually solves the "unbounded recursion" problem (Rule 3.3).
204
+
*`boundedDepthOfOnNextAndRequestRecursion` – which must be overridden when verifying synchronous Publishers.
205
+
This number returned by this method will be used to validate if a `Subscription`adheres to Rule 3.3 and avoids "unbounded recursion".
209
206
210
207
### Timeout configuration
211
208
Publisher tests make use of two kinds of timeouts, one is the `defaultTimeoutMillis` which corresponds to all methods used
@@ -215,7 +212,7 @@ by the Publisher.
215
212
216
213
In order to configure these timeouts (for example when running on a slow continious integtation machine), you can either:
217
214
218
-
**Use env variables** to set these timeouts, in which case the you can just:
215
+
**Use env variables** to set these timeouts, in which case the you can do:
219
216
220
217
```bash
221
218
export DEFAULT_TIMEOUT_MILLIS=300
@@ -472,7 +469,7 @@ public class MyIdentityProcessorVerificationTest extends IdentityProcessorVerifi
472
469
473
470
@Override
474
471
publicPublisher<Integer>createFailedPublisher() {
475
-
// return Publisher that just signals onError instead of null to run additional tests
472
+
// return Publisher that only signals onError instead of null to run additional tests
476
473
// see this methods JavaDocs for more details on how the returned Publisher should work.
0 commit comments