unit testing a freeze
Dominik Haumann
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?
Thanks
Dominik
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Dario Freddi
> 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,
QTimer timer;
QEventLoop e;
connect(&timer, SIGNAL(timeout()), &e, SLOT(quit()));
connect(myObject, SIGNAL(finished()), &e, SLOT(quit()));
myObject->problematicAsyncCall();
timer.setSingleShot(true);
timer.start(5000);
e.exec();
QVERIFY(timer.isActive());
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.
Frank Reininghaus
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,
>
> QTimer timer;
> QEventLoop e;
> connect(&timer, SIGNAL(timeout()), &e, SLOT(quit()));
> connect(myObject, SIGNAL(finished()), &e, SLOT(quit()));
> myObject->problematicAsyncCall();
> timer.setSingleShot(true);
> timer.start(5000);
> e.exec();
>
> QVERIFY(timer.isActive());
I think the same could be achieved like this:
myObject->problematicAsyncCall();
QTest::kWaitForSignal(myObject, SIGNAL(finished()), 5000)
Best regards,
Frank
Dario Freddi
Correct - I forgot we were using KDE's infrastructure and not pure Qt
Dominik Haumann
> Il 21 marzo 2012 22:29, Dominik Haumann <dhau...@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 :)
Thanks
Dominik
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Alex Fiestas
that might work as well though it depends on unix signals which are crappy.
Milian Wolff
> 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>
Cheers
--
Milian Wolff
ma...@milianw.de
http://milianw.de
Milian Wolff
> On Thursday, March 22, 2012 10:47:18 Milian Wolff wrote:
> > Why not Zoidberg? Uhm I mean: ctest --timeout <seconds>
>
> test in CMakeLists.txt?
yes:
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_test:TIMEOUT
Bye
Dario Freddi
> On Thursday 22 March 2012 11:08:35 Dominik Haumann wrote:
>> On Thursday, March 22, 2012 10:47:18 Milian Wolff wrote:
>> > Why not Zoidberg? Uhm I mean: ctest --timeout <seconds>
>>
>> That would do the trick. Is it possible to set this timeout for a single
>> test in CMakeLists.txt?
>
> yes:
>
> http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_test:TIMEOUT
Neat, didn't know about that, thanks
/me notes down
>
> Bye
> --
> Milian Wolff
> ma...@milianw.de
> http://milianw.de
>
>
Dominik Haumann
> On Thursday 22 March 2012 11:08:35 Dominik Haumann wrote:
> > On Thursday, March 22, 2012 10:47:18 Milian Wolff wrote:
> > > Why not Zoidberg? Uhm I mean: ctest --timeout <seconds>
> >
> > That would do the trick. Is it possible to set this timeout for a single
> > test in CMakeLists.txt?
>
> yes:
>
> http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_test:TIMEOUT
set_tests_properties(kate-bug286887_test PROPERTIES TIMEOUT 2)
Works - exactly what I was looking for, thanks!