is there a simple way to unit test a freeze? Like if the test needs more than 5 seconds, fail?
One way would be to create a thread, start the freeze unit test, and if the thread does not finish in some time period, kill it and fail. But that's rather complicated for such a simple thing. Maybe QTest already provides some nice feature?
Il 21 marzo 2012 22:29, Dominik Haumann <dhaum...@kde.org> ha scritto:
> Moin,
> is there a simple way to unit test a freeze? > Like if the test needs more than 5 seconds, fail?
There's no straightforward way to check afaik and I don't really like the thread approach. What are you trying to verify? If the context is the one of a synchronous operation, I am afraid this might be very tricky, since there is no easy way you can interrupt a synchronous call identifying its context. Supposing your routine is asynchronous,
In case the freeze is on a synchronous operation, the only thing you can do is crashing the unit test I am afraid. But again, you have a number of problems with synchronization and stuff. Supposing your call does not block Qt's event loop, you could for example create a timer again which connects to a slot performing stuff like:
QVERIFY(false); qApp->exit(1);
If the event loop is blocked, a thread is the only solution but I see multiple shortcomings with that approach.
> One way would be to create a thread, start the freeze unit test, and if the > thread does not finish in some time period, kill it and fail. But that's > rather complicated for such a simple thing. Maybe QTest already provides some > nice feature?
> Il 21 marzo 2012 22:29, Dominik Haumann ha scritto: >> Moin,
>> is there a simple way to unit test a freeze? >> Like if the test needs more than 5 seconds, fail?
> There's no straightforward way to check afaik and I don't really like > the thread approach. What are you trying to verify? If the context is > the one of a synchronous operation, I am afraid this might be very > tricky, since there is no easy way you can interrupt a synchronous > call identifying its context. Supposing your routine is asynchronous,
> Am 22. März 2012 01:11 schrieb Dario Freddi: >> Il 21 marzo 2012 22:29, Dominik Haumann ha scritto: >>> Moin,
>>> is there a simple way to unit test a freeze? >>> Like if the test needs more than 5 seconds, fail?
>> There's no straightforward way to check afaik and I don't really like >> the thread approach. What are you trying to verify? If the context is >> the one of a synchronous operation, I am afraid this might be very >> tricky, since there is no easy way you can interrupt a synchronous >> call identifying its context. Supposing your routine is asynchronous,
On Thursday, March 22, 2012 01:11:53 Dario Freddi wrote:
> Il 21 marzo 2012 22:29, Dominik Haumann <dhaum...@kde.org> ha scritto: > > Moin,
> > is there a simple way to unit test a freeze? > > Like if the test needs more than 5 seconds, fail?
> There's no straightforward way to check afaik and I don't really like > the thread approach. What are you trying to verify?
Kate: Switch to block selection, place cursor after end of line, press ctrl+shift+left. This freezes Kate forever at 100% cpu.
We have a fix for that, but I want to add a unit test to prevent this from happening again. It's not an asynchronous operation.
It would help if we could tell the the unit test launcher script that the test should be killed if it did not finish within 5 seconds. But guess this is not possible atm.
A thread is a problem as Kate Part is not thread safe. So if I call the problematic function from a thread, the main thread may still process e.g. paint events for the text view (the overall behavior is undefined). Probably, processing events in the meantime can be suppressed.
I'll play around with what you suggested, maybe it can be done with a few lines of code :)
> If the context is > the one of a synchronous operation, I am afraid this might be very > tricky, since there is no easy way you can interrupt a synchronous > call identifying its context. Supposing your routine is asynchronous,
> In case the freeze is on a synchronous operation, the only thing you > can do is crashing the unit test I am afraid. But again, you have a > number of problems with synchronization and stuff. Supposing your call > does not block Qt's event loop, you could for example create a timer > again which connects to a slot performing stuff like:
> QVERIFY(false); > qApp->exit(1);
> If the event loop is blocked, a thread is the only solution but I see > multiple shortcomings with that approach.
> Hope this helped.
> > One way would be to create a thread, start the freeze unit test, and if > > the thread does not finish in some time period, kill it and fail. But > > that's rather complicated for such a simple thing. Maybe QTest already > > provides some nice feature? >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
On Wednesday 21 March 2012 22:29:53 Dominik Haumann wrote:
> Moin,
> is there a simple way to unit test a freeze? > Like if the test needs more than 5 seconds, fail?
> One way would be to create a thread, start the freeze unit test, and if the > thread does not finish in some time period, kill it and fail. But that's > rather complicated for such a simple thing. Maybe QTest already provides > some nice feature?
Why not Zoidberg? Uhm I mean: ctest --timeout <seconds>
