Bring back TCK for 0.4.0

[ktoso]

Initial draft of 0.4.0 TCK.
Submitting this PR "early", as in it's not completely done, but I want to get your feedback as soon as possible.

Please have a look at PublisherVerification and SubscriberVerification first - the specs are documented and link to the respective points in the spec.

IdentityProcessorVerification delegates to subscriber and publisher tests, as well as contains some additional specs which I have not yet reviewed if they make sense under the 0.4.0.M2 spec.

Some initial ideas around #87 are also included in this PR, and I would welcome opinions about it. The idea is around maxElementsFromPublisher, which implementors can override, and then if it's 1 for example, but my test requires at least 3 elements, we can mark this test as skipped.

In order to run the TCK against your implementations (please do report if I got anything wrong) you can publish it locally: sbt publishLocal (to local ivy repo) or sbt publishM2 (to local maven repo).

This PR aims to eventually resolve #85
Also addresses "limited publishers"- #87

Thanks in advance for your feedback and comments!

Depends on:

• Synch docs and examples with spec - request(long) #93 Synch docs and examples with spec - request(long)

Implementations passing the TCK:

• akka streams - passes on branch, needs rebase // currently WIP
• reactor - passes
• ratpack - currently WIP
• rx - soon to be WIP
• vert.x - WIP on TCK compat

[ktoso]

not yet fully cleaned up (contains tests from old tck)

[ktoso]

Pushed some updates, the int => long migration is a separate PR now, and this PR depends on it – I'll rebase again once it's in (commit ed9465a). Still needs work around supporting 1 element publishers as well as more "stochastic" tests if we want to go that road.

[rkuhn]

given the Java audience I’d rename this one to isNonFatal to be able to statically import it

[ktoso]

👍

[ktoso]

(also made constructor private – no need for instances of NonFatal)

[rhart]

Hi, I've been looking at Subscriber blackbox tests today. Has been pretty pain free so far, thanks for all this hard work!

I wonder whether the TCK could provide the helper Publisher? Why does the implementator need to provide this?

[smaldini]

Making an agnostic publisher is not that easy as it should support a minimum scope of the rules itself. If that is an issue because the publisher in ratpack is tied to a web context, feel free to pull a dependency onto reactor-core 👍 (hehe) and use:

Streams.defer(....); to create your publisher (Stream implements Publisher).

[rhart]

Good plug for Reactor :) Good idea though too, might be worth a mention in the readme?

[ktoso]

The initial idea of the helperPublisher is to be able to test your code in presence of different types publishers because even with the spec there's some room for nuances in implementations which you may want to try to test against.

If there's enough demand I think we could provide a "simpleIterablePublisher" but I'd opt for keeping the method abstract, so you actively think about and select what publisher you're running with. Opinions?

[ldaley]

I agree that the tester should supply the impl.

On Sun, Sep 7, 2014 at 1:50 AM, Konrad Malawski [email protected]
wrote:

Tthe initial idea of the helperPublisher is to be able to test your code in presence of different types publishers because even with the spec there's some room for nuances in implementations which you may want to try to test against.

If there's enough demand I think we could provide a "simpleIterablePublisher" but I'd opt for keeping the method abstract, so you actively think about and select what publisher you're running with. Opinions?

Reply to this email directly or view it on GitHub:
#91 (comment)

[ktoso]

@reactive-streams/contributors Ping. Any opinions if we can merge this and perhaps release another milestone? We need a few more votes I believe.

It would make things easier for devs who are now trying to implement their libraries, and test drive the TCK.

[viktorklang]

I think it makes total sense to merge this and cut another milestone release of 0.4 as it'd make it much easier for implementors to try it out and give feedback.

[smaldini]

I would expect at least another implementor to use it. What about Ratpack and Vert.x @alkemist @purplefox ?
Also @benjchristensen work on reactiveStreams on top of RxJava should complete the feedback round very nicely.

[ldaley]

We're already using it, if that's what you mean.

https://github.com/ratpack/ratpack/tree/master/ratpack-core/src/test/groovy/ratpack/stream/tck

[smaldini]

Ha does it fully pass ?

[ldaley]

The tests that are there are passing yes. We have a few more tests to add though.

[smaldini]

If you don't have any specific feedbacks I think we have our 3 implementors to go for 0.4.0. We might wait for Vert.x and RxJava before 1.0 then :)

[viktorklang]

@smaldini We were only talking about releasing an M3 of 0.4 so far :), and then get some extra feedback before we release 0.4, then we need to achieve the goals for 1.0 before we can ship 1.0-RC1.

I'm really proud of what we have achieved so far!

[smaldini]

I think nothing prevents us to go for 0.4 but if the scope is only M3 we should really do it like today :)

[viktorklang]

@smaldini I'd be happy with a 0.4.0-M3 today :)

[rkuhn]

@benjchristensen @purplefox @tmontgomery @mariusaeriksen we need two more LGTM in order to proceed with this (i.e. merge it and release the artifacts as 0.4.0.M3 so that further TCK validation can proceed more easily), is there anything holding this back?

[benjchristensen]

Nothing I'm aware of but I haven't had time yet to try it. I imagine I'll want the new artifacts when I try so I'm good releasing since this isn't 1.0.

[tmontgomery]

I'll defer to you guys on this.

[smaldini]

All right I guess we have our two chaps. Let's accept the Konrad PR and proceed then.

[ktoso]

So great to see this merged, thanks a lot for all the feedback and cooperation guys (and for the upcoming feedback once others try it :-))!

[smaldini]

Thanks to you to make it real :) that was great to just polish a couple detail and beta test the beast. Really impressive work. Waiting for Maven Central to sync on 0.4.0

[viktorklang]

Thanks everyone, I can't believe how close we are now! :)