Mailingliste - Einträge 2015
Die Mailingliste ist seit Juli 2022 geschlossen, dient aber weiterhin als Informationsarchiv zu QF-Test.
Wenn Sie über Neuerungen zu QF-Test informiert bleiben wollen, können Sie einfach unseren Newsletter abonnieren:
Newsletter abonnieren
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [QF-Test] Shouldn't "Wait for client to connect" check if the client is (still) running?
Hi Michael, unfortunately there are many common cases where the process started by QF-Test is not the same as the one that connects to QF-Test. In some cases even the parent/child process relationship becomes impossible to track. The most notable example is Java WebStart which always starts a second process and terminates the first one. Thus, whether a process terminates or not is irrelevant, QF-Test has to wait for an SUT connection until the entire timeout period has elapsed. In addition to that, you need to be able to access already terminated clients, e.g. when checking their exit code or retrieving their output. Consequently a NoSuchClientException is only thrown if no client be the given name was ever started (or is no longer among the recently terminated processes). That said, your short cut implementation for the case where the client terminates immediately is basically fine. I'd modify it slightly, but I guess that's just a matter of taste: + Start SUT client: $(client) + Try + Wait for client to terminate (timeout 2000) + call qfs.utils.testrun.stop.stopTestRun // terminated quickly + Catch ClientNotTerminatedException + Try + Wait for client to connect + Catch ClientNotConnectedException + ... deal with it somehow ... Best regards, Greg Michael Pruemm <eso@?.org> writes: > 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 > _______________________________________________ > qftest-list mailing list > qftest-list@?.de > http://www.qfs.de/mailman/listinfo/qftest-list -- Gregor Schmid E: gregor.schmid@?.de T: +49 8171 38648-11 F: +49 8171 38648-16 Quality First Software GmbH | www.qfs.de Tulpenstr. 41 | 82538 Geretsried | Germany GF Gregor Schmid, Dr. Martina Schmid, Karlheinz Kellerer HRB München 140833
|
Wir verwenden Cookies zur anonymisierten Auswertung Ihres Besuchs auf unserer Webseite durch »Matomo«. Dafür benötigen wir Ihr Einverständnis, welches für zwölf Monate gilt. Ein Widerruf bzw. Opt-out ist jederzeit auf unser Datenschutz-Seite möglich.
1. Funktionale Cookies
Wir verwenden funktionale Cookies, um die Basisfunktionalität der Webseite zu gewährleisten.
2. Performance und Statistik Cookies
Wir verwenden Matomo zur Analyse und Optimierung unserer Webseite. Cookies erlauben eine anonyme Erfassung der Informationen und helfen uns, Ihnen einen benutzerfreundlichen Besuch unserer Webseite zu bieten.
Dieses Cookie enthält eine eindeutige jedoch pseudonymisierte Matomo-interne Besucher-ID zur Erkennung wiederkehrender Besucher.
Dieses Cookie wird verwendet, um zu tracken, von welcher Website der anonymisierte Benutzer auf die Website gekommen ist.
Das Session Cookie von Matomo wird verwendet, um die Seitenanforderungen des Besuchers während der Sitzung zu verfolgen.
wird erzeugt und versucht sofort wieder zu löschen (zur Prüfung, ob der Browser des Besuchers Cookies unterstützt).
Kurzzeit-Cookies für temporäre Besuchsdatenspeicherung.
Kurzzeit-Cookies für temporäre Besuchsdatenspeicherung.