Qt-interest Archive, June 2007
Unit test for QTcpServer and QTcpSocket
Message 1 in thread
Hi,
I need a unit test containing a QTcpServer and QTcpSocket to check,
if the client socket can communicate correctly with the tcp server.
But the QTcpServer seems to need an event loop - and my calls to
QApplication::processEvents() aren't enough to simulate a real event loop :(
Has anybody an idea how to solve this or is it impossible to write
such a test using the QTestLib? Any hints are appreciated.
Best Regards,
Christian
--
[ signature omitted ]
Message 2 in thread
try processEvents(QEventLoop::DeferredDeletion,100)
this should be the same as "the real event loop".
Cheers,
Peter
> -----Original Message-----
> From: Christian Dähn [mailto:daehn@xxxxxxxxxx]
> Sent: Tuesday, June 26, 2007 3:07 PM
> To: qt-interest@xxxxxxxxxxxxx
> Subject: Unit test for QTcpServer and QTcpSocket
>
> Hi,
>
> I need a unit test containing a QTcpServer and QTcpSocket to check,
> if the client socket can communicate correctly with the tcp server.
>
> But the QTcpServer seems to need an event loop - and my calls to
> QApplication::processEvents() aren't enough to simulate a real event loop
> :(
>
> Has anybody an idea how to solve this or is it impossible to write
> such a test using the QTestLib? Any hints are appreciated.
>
> Best Regards,
> Christian
--
[ signature omitted ]
Message 3 in thread
Hi,
> try processEvents(QEventLoop::DeferredDeletion,100)
> this should be the same as "the real event loop".
Thnx! I tested this - but with no difference :(
The QTcpServer receives an incoming connection,
but doesn't send the readyRead() signal.
If I modify the main() to just run a simple
qApp->exec() everything works fine - but this
doesn't work in unit tests as fas as I know.
Regards,
Chris
--
[ signature omitted ]
Message 4 in thread
That is strange. If you have a look at the code that is executed in app.exec() you can see that it boils down to these lines in qeventloop.cpp:
while (!d->exit)
processEvents(flags | WaitForMoreEvents | processEventsFlag(QEventLoop::DeferredDeletion));
I suspect that there is something else which you are doing differently in the test case.
Cheers,
Peter
> -----Original Message-----
> From: Christian Dähn [mailto:daehn@xxxxxxxxxx]
> Sent: Tuesday, June 26, 2007 4:31 PM
> To: qt-interest@xxxxxxxxxxxxx
> Subject: RE: Unit test for QTcpServer and QTcpSocket
>
> Hi,
>
> > try processEvents(QEventLoop::DeferredDeletion,100)
> > this should be the same as "the real event loop".
>
> Thnx! I tested this - but with no difference :(
>
> The QTcpServer receives an incoming connection,
> but doesn't send the readyRead() signal.
>
> If I modify the main() to just run a simple
> qApp->exec() everything works fine - but this
> doesn't work in unit tests as fas as I know.
>
> Regards,
> Chris
--
[ signature omitted ]
Message 5 in thread
Hi,
> That is strange. If you have a look at the code that is executed in app.exec() you can see that it boils down to these lines in qeventloop.cpp:
>
> while (!d->exit)
> processEvents(flags | WaitForMoreEvents | processEventsFlag(QEventLoop::DeferredDeletion));
>
> I suspect that there is something else which you are doing differently in the test case.
Very strange - even a QThread with QApplication::processEvents() running in an
endless loop didn't help at all - but I'll test this again with your hints
Regards,
Chris
--
[ signature omitted ]
Message 6 in thread
On Tuesday 26 June 2007 15:07:05 Christian Dähn wrote:
> Hi,
>
> I need a unit test containing a QTcpServer and QTcpSocket to check,
> if the client socket can communicate correctly with the tcp server.
> But the QTcpServer seems to need an event loop - and my calls to
> QApplication::processEvents() aren't enough to simulate a real event loop
> :(
>
> Has anybody an idea how to solve this or is it impossible to write
> such a test using the QTestLib? Any hints are appreciated.
Why not use the waitFor*() functions instead?
--
[ signature omitted ]
Message 7 in thread
Hi,
> Why not use the waitFor*() functions instead?
Internally I uses the waitFor.. class as often as possible -
but the QTcpServer uses signals/slots to manage incoming
connections - and that doesn't work in my unit test :(
Christian
--
[ signature omitted ]
Message 8 in thread
On Wednesday 27 June 2007 09:47:51 Christian Dähn wrote:
> Hi,
>
> > Why not use the waitFor*() functions instead?
>
> Internally I uses the waitFor.. class as often as possible -
> but the QTcpServer uses signals/slots to manage incoming
> connections - and that doesn't work in my unit test :(
From http://doc.trolltech.com/4.3/qtcpserver.html#details:
"Although QTcpServer is mostly designed for use with an event loop, it's
possible to use it without one. In that case, you must use
waitForNewConnection(), which blocks until either a connection is available
or a timeout expires."
http://doc.trolltech.com/4.3/qtcpserver.html#waitForNewConnection
Use that and you should be able to do exactly what you want. FWIW, I've
written unit tests that do exactly this, and it works very well :)
--
[ signature omitted ]
Message 9 in thread
Hi,
> From http://doc.trolltech.com/4.3/qtcpserver.html#details:
>
> "Although QTcpServer is mostly designed for use with an event loop, it's
> possible to use it without one. In that case, you must use
> waitForNewConnection(), which blocks until either a connection is available
> or a timeout expires."
>
> http://doc.trolltech.com/4.3/qtcpserver.html#waitForNewConnection
>
> Use that and you should be able to do exactly what you want. FWIW, I've
> written unit tests that do exactly this, and it works very well :)
That's right - that solves the problem for the unit test.
But that includes that I have to change my whole application design
to just get this small unit test running ;) Thats very funny,
if I mention that the usage of signals and the complete redesign
of my app was formerly based on hints of your collegues (Trolltech) ;)
Summing up: No chance to test the existing design in unit tests
without having to completely rewrite the whole tcp server, right?
Christian
--
[ signature omitted ]
