Mailing-List: contact dev-help@mina.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@mina.apache.org
Received-SPF: neutral (nike.apache.org: 209.85.218.211 is neither permitted
 nor denied by domain of niklas@protocol7.com)
MIME-Version: 1.0
In-Reply-To: <4A769A43.8040802@brainlounge.de>
References: <8833dc800907142314w263f916bw37e01d7641b4740c@mail.gmail.com>
	 <4A769A43.8040802@brainlounge.de>
Date: Mon, 3 Aug 2009 12:20:24 +0200
Message-ID: <8833dc800908030320l77647955t36e855147cfc553e@mail.gmail.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
From: Niklas Gustavsson <niklas@protocol7.com>
To: dev@mina.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 3, 2009 at 10:05 AM, Bernd Fondermann<bf_jak@brainlounge.de> wr=
ote:
> 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 you=
rs.
>
> 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 =A0from 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.

/niklas