On Mon, Jun 22, 2009 at 13:48, Michael Jakl<jakl.mich...@gmail.com> wrote: > Hi! > > On Sun, Jun 21, 2009 at 22:48, Niklas Gustavsson<nik...@protocol7.com> wrote: >> On Sun, Jun 21, 2009 at 10:21 PM, Bernd Fondermann<bf_...@brainlounge.de> >> wrote: >>> But we're kind of talking very theoretical here (otherwise my answer >>> could have been shorter and there'd be somebody still listening down >>> here). Let's talk about a concrete example. >> >> Agreed, I'll see what I can come up with :-) > > What about defining a high-level test suite which is abstract enough > to be carried out by more than one XMPP library? I'm thinking of an > abstracted API which can run on Smack and other libs for > - openeing a connection, > - registering useres, > - sending messages and the like.
This goes beyond the scope of this server implementation. > Since the clients run under the same hood, checking whether a message > arrives within a certain amount of time should be easy. With more than > one client-implementation the chances are high that we catch > interoperability bugs earlier. +1 for the general idea. -0 for doing this. Vysper is about a spec conforming server implementation, not about clients. If there are clients with interop problems, well, just fix *them* first (but let's still be liberal in what the server accepts, within the scope of the spec). If the server has a problem, write a test for that. Just as a side note: there are no guarantees for delivery/quality of service/realtime requirements in the XMPP spec. if the server decides to delay a message (because he has 100K stanzas in the queue) he is perfectly entitled to do so. > For example if I want to test my pubsub implementation I'd add 3 > users, one publisher and two subscribers. When publishing a message, > the two subscribers should receive a notification within a certain > amount of time (some seconds), if not we've got a problem. So you want to test the general stanza delivery. go ahead and do so! this is worthwhile. but this is nothing the pubsub implementation should be concerned about. pubsub tests should only test pubsub specifics. > This, of course, is complementary to the unit (whitebox) tests. > > Just a few early thoughts on this. Bernd
