On Sun, Jun 21, 2009 at 11:14 AM, Bernd Fondermann<[email protected]> wrote:
> For testing new functionality (mostly handlers), starting the server is
> not neccessary (and that's a big plus). Just testing the handler in
> isolation is usually sufficient.
I should have pointed out that I did not suggest to in any way replace
the current testing (nor step away from the design that allows
handlers and other classes to be tested in isloation), that should
still be done!
> At some point, we might need that integration tests, to make sure
> everything works properly together, though.
Yeah, that's kind of the experience we've had with FtpServer. The
integration tests has located tons of bugs, and allows us easily to
write tests for cases reported by users ("server does this when my
client does that").
> What do you intend to use this end-to-end testing for?
I would say that we should intend to test most, if not all, of the
client facing functionality this way (as well as with more
fine-grained test on each class).
> Integration tests for XMPP may prove difficult, because
> + XMPP is XML and the way elements are closed or allowance of arbitrary
> whitespaces can add for a lot of noise, elements order may be arbitrary etc.
> + stanzas may come out of order, too
> + extensions are manyfold
> + tracking session state is easier with our own testing facilities
I probably (surely) don't understand all the details here. But, my
idea would be to use Smack as the client which at least should isolate
us as much as we want from the protocol (but still allow us to create
arbitrary packages for testing odd cases). I also think this would
handle out of order stanzas and extensions. Not sure about session
state.
Again, let me point out that these tests should never replace the
current tests but merely test at a different abstraction.
/niklas
