+tck #232 explain which tests are mendatory to be "compliant"

Author: ktoso

tck/README.md

@@ -479,6 +479,22 @@ public class SkippingIdentityProcessorTest extends IdentityProcessorVerification
 }
 ```
 
+## Which verifications must be implemented by an compliant implementation?
+In order to be considered an Reactive Streams compliant we require implementations to cover their
+Publishers and Subscribers with TCK verifications. Of course, if your library is only including
+Subscribers, you do not have to implement Publisher tests. The same applies to `IdentityProcessorVerification` -
+you do not need to implement it if your library does not contain Processors.
+
+In the case of Subscriber Verification are two styles of verifications to available: Blackbox or Whitebox.
+We *strongly* recommend testing your `Subscriber` with the `SubscriberWhiteboxVerification` as it is able to
+verify most of the specification. The `SubscriberBlackboxVerification` should only be used as a fallback,
+once you are sure implementing the whitebox version will not be possible for your implementation - if that happens
+feel free to open a ticket on the `reactive-streams/reactive-streams-jvm` project explaining what stopped you from
+implementing the whitebox verification.
+
+In summary: we require implementations to use Verifications for the parts of the specification that they implement,
+and suggest using the whitebox verification over blackbox for the subscriber whenever possible.
+
 ## Upgrade story
 
 **TODO** - What is our story about updating the TCK? How do we make sure that implementations don't accidentally miss some change in the spec, if the TCK is unable to fail verify the new behavior? Comments are very welcome, discussion about this is under-way in [Issue #99 – TCK Upgrade Story](https://github.com/reactive-streams/reactive-streams/issues/99).

tck/src/test/java/com/example/ExampleTest.java

@@ -0,0 +1,4 @@
+package com.example;
+
+public class ExampleTest {
+}