List Icon
Mailing list Archive

2019 up to July 2022 | 20182017  |  2016  2015 2014 | 2013

The mailing list has been closed since July 2022, but continues to serve as an archive of information about QF-Test.
But if you want to stay informed about news about QF-Test, you can simply
Subscribe to Newsletter  

To get up-to-date information about each release - including minor releases - you can
subscribe to the RSS feed or follow us on social media.
Alternatively, QF-Test also provides release information itself.

Another source of information is our blog, where there are current articles on general topics, on the company QFS and also various "how-tos"
subscribe to blog


[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?


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

Thanks for the long explanation. I was suspecting that it was not so easy to determine if the client is still running.

On 19.07.2015, at 21:15, Gregor Schmid <Gregor.Schmid@?.de> wrote:

> 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 ...

Yes, this looks better, even to me :-)

It didn't occur to me to use "Wait for process to terminate" here (as you do). I guess it was Friday afternoon, and it was hot ;-)

- Michael