Clarification on Whitebox subscriber verification

[purplefox]

I am attempting to implement Whitebox subscriber verification as explained in the docs, but I am unsure what I supposed to do in the createSubscriber() method.

I understand that this should return an instance of my subscriber class, but with the methods overridden to call the probe, but I do not understand what "in addition to normal Subscriber work that you're testing," means.

Does this mean I should call the super class method first before calling the probe, or perhaps I should call the super class method after I call the probe, or perhaps something else?

Any clarification on what is expected by the TCK here would be greatly appreciated :)

[ktoso]

[...] what "in addition to normal Subscriber work that you're testing," means.

Since the TCK is aimed at testing real implementations, they'll probably be doing something with the received data (emit it somewhere, write it to a file, drop it, ...), this is what is meant by "normal subscribe work". Basically it boils down to: You should not write a subscriber just for the sake of "I have a subscriber which passes the TCK", and then have completely different ones do the actual work in your library :-)

If you can, you can adapt an existing implementation by subclassing - calling the probe methods where needed (see tck/README.md for an example) and call super so that it actually performs the work you're testing. If you can't subclass, perhaps delegating to the tested subscriber would work... it's dependent on what hooks your impl has and if it's async / sync etc.

Hope this helps

[purplefox]

Thanks,

I got that I should subclass my Subscriber method by looking at the example in the README.

However that example does not call super class implementation, and I can't infer from that whether the probe should be called before or after the call to the super class.

[purplefox]

(I think it would be helpful to edit the example in the README so it actually calls the super class methods)

[ktoso]

I'm not sure we will be able to give an universal recipe for this... Feels like the exact "where" are implementation specific.

They may be doing weird async things in there etc.
When updating the README #237 I'll try to think of a better example, but my gut feeling is there isn't an one-size-fits-all solution here.

[purplefox]

I don't think we need a universal recipe here.

Just want to know what I should be doing in the case that the Subscriber class is easily subclassable, like ours is (and many others will be).

[ktoso]

Yeap, agree on that one :-)

[viktorklang]

Can this be closed or does something need to be answered/fixed?

[ktoso]

Not yet, the PR fixing this precise question is not in yet - hoping to get it in today.
It's about prepping an example of using whitebox in the simplest case.

[viktorklang]

Awesome, thanks Konrad

[ktoso]

And the PR came into existence! #244