Skip to content

Commit cff1bdd

Browse files
committed
Addresses PR review comments for #246
1 parent 7030855 commit cff1bdd

File tree

1 file changed

+8
-11
lines changed

1 file changed

+8
-11
lines changed

tck/README.md

Lines changed: 8 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -87,10 +87,8 @@ Usually this means that this test case can yield false positives ("be green") ev
8787

8888
<a name="type-untested"></a>
8989
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!
9492

9593
### Test isolation
9694

@@ -200,12 +198,11 @@ public class RangePublisherTest extends PublisherVerification<Integer> {
200198

201199
Notable configuration options include:
202200

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
206203
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".
209206

210207
### Timeout configuration
211208
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.
215212

216213
In order to configure these timeouts (for example when running on a slow continious integtation machine), you can either:
217214

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:
219216

220217
```bash
221218
export DEFAULT_TIMEOUT_MILLIS=300
@@ -467,7 +464,7 @@ public class MyIdentityProcessorVerificationTest extends IdentityProcessorVerifi
467464

468465
@Override
469466
public Publisher<Integer> createFailedPublisher() {
470-
// return Publisher that just signals onError instead of null to run additional tests
467+
// return Publisher that only signals onError instead of null to run additional tests
471468
// see this methods JavaDocs for more details on how the returned Publisher should work.
472469
return null;
473470
}

0 commit comments

Comments
 (0)