On Mon, Aug 3, 2009 at 10:05 AM, Bernd Fondermann<[email protected]> 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. /niklas
