List Icon
Archiv Mailingliste

2019 bis Juli 2022  2018  | 2017 2016 2015 | 2014 | 2013

Die Mailingliste ist seit Juli 2022 geschlossen, dient aber weiterhin als Informationsarchiv zu QF-Test.
Wenn Sie aber über Neuerungen zu QF-Test informiert bleiben wollen, können Sie einfach unseren
Newsletter abonnieren

Um aktuell die Informationen zu jeder Release - auch Minor Releases - zu bekommen, können Sie den
RSS-Feed abonnieren oder uns in sozialen Medien folgen.
Alternativ bietet QF-Test auch selbst eine Versionsinformation an.

Eine weitere Informationsquelle ist unser Blog, in dem es aktuelle Beiträge zu allgemeinen Themen, zur Firma QFS und auch diverse "How-Tos" gibt:
Blog abonnieren


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[QF-Test] Shouldn't "Wait for client to connect" check if the client is (still) running?


  • Subject: [QF-Test] Shouldn't "Wait for client to connect" check if the client is (still) running?
  • From: Michael Pruemm <eso@?.org>
  • Date: Fri, 17 Jul 2015 15:13:47 +0200

Hi all,

I just had the following interesting scenario: My tests start the
client, which immediately fails because the JVM cannot allocate
sufficient memory. Right after the "Start SUT client", I wait for the
client to connect. This fails of course after the timeout with a
"ClientNotConnectedException".

This is of course technically correct, since the client did not connect.

However, since the client failed to start immediately, it was not even
running when the "Wait for client to connect" started to execute. In
that case, I would expect a "NoSuchClientException".

The description for ClientNotConnectedException seems to back me up here:

It differs from a NoSuchClientException in that there is an active
process for that name but no RMI connection.

I just confirmed that behavior by creating a new "Wait for client to
connect" node with a time-out of 2s and a client name of "foo". When I
execute this, it leads to a ClientNotConnectedException instead of a
NoSuchClientException.


To work around this problem, I am using this:

+ Start SUT client: $(client), delay after 2000 -- client starts slowly
+ If "${qftest:client.exitcode.$(client)}" != ""
  + call qfs.utils.testrun.stop.stopTestRun
+ Try
  + Wait for client to connect
  + Catch ClientNotConnectedException
    + ... deal with it somehow ...

Is this the best approach?


Here a few more details about my setup: QFTest 4.0.5; the client is a
Java application that gets started via a shell script.

- Michael