mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niklas Gustavsson <nik...@protocol7.com>
Subject Re: svn commit: r794145 - in /mina/sandbox/vysper/trunk/src/test/java/org/apache/vysper/xmpp/modules/extension/xep0199_xmppping: AbstractIntegrationTestCase.java PingPacket.java XmppPingIntegrationTestCase.java XmppPingNoSupportIntegrationTestCase.ja
Date Mon, 03 Aug 2009 10:20:24 GMT
On Mon, Aug 3, 2009 at 10:05 AM, Bernd Fondermann<bf_jak@brainlounge.de> wrote:
> Niklas Gustavsson wrote:
> This test perfectly demonstrates the pros and cons of integration
> testing of socket based protocols.
> All test run within about 5.3 seconds on my machine, probably less on yours.
> The integration test _alone_ takes 5 seconds! (Which makes me want to
> disable it. Suggestion: Can we move integration tests to a separate
> source folder so they can easily be excluded  from running?)

Yes, either we can move it to a separate source folder (activated by a
different Maven profile as suggested by Emmanuel) or to a different
module. I'm all for doing this if we decide to keep doing integration
tests (which I think we should).

> Why is that? The tests sets up the whole server infrastructure. This
> adds overhead to the test, but is not the cause for the long running
> time. It's Thread.sleep(5000). This is a common problem with testing
> async stuff. Maybe we can reduce this to 100 ms, but this might cause
> spurious test failures for some, which are hard to reproduce.

I don't think we do a Thread.sleep() anywhere in the integration
tests, or am I missing something? Instead we use Smacks listener
support, with a timeout of 5000 ms (in the sendSync method). Doing
that, I think we return as soon as possible (or at least as soon as
Smack lets us).

> A better approach - if possible - would be to have a listener kicking in
> when the async processing is finished, causing some kind of continuation
> to finish of the test.

This is what we're already doing, right?

> In general I'd stick with my original statement to discourage using this
> kinds of tests for handlers.

I find these tests have been quite powerful so far, detecting two or
three bugs in Vysper already.


View raw message