qtforum.de

Spricht was dagegen, QTest::qWait in regulärem Code zu verwenden, also Code, der ausgeliefert wird und nicht zum Testen gedacht ist? Ich fände es sehr praktisch, in meinem Code Konstrukte verwenden zu können wie im Beispiel der Doku Es widerstrebt mir allerdings QTest in Nicht-Testcode einzubauen. Gibt es Gründe dafür oder dagegen?

Es spricht nichts wirklich dagegen aber blockierende Aufrufe wie hier sollten vermieden werden. Ist mit Signal/Slots ja eigentlich auch nicht das Problem.
Also: ja du kannst es verwenden aber es der Ansatz ist falsch.

Kommt auch drauf an, was man mit machen will ...

wenn ich mir eine Software runterlade/kaufe und die mit qttest geliefert wird und davon abhängig ist, würd ich erst mal denken das ich das falsche Produkt habe ^^
Also nen guten EIndruck macht das nicht ^^

Und genau an solchen stellen trennt sich auch die Spreu vom Weizen ... ^^
nichtllockierende aufrufe Pollen lassen ist ... urks, aber manchmal unumgänglich
dafür extra timer zu schreiben ist lästig, nervig ... (besonders wenn man kein Qt an der Stelle hat).
Trotzdem sollte man es machen, dem Produkt - Anwender zu Liebe
Jeglicher Hack / Schmutz ist nur für Prototypen ok, aber ned für Release Code !

(mit blockierenden aufrufen isses minimum genau so eklig, wenn die selber keinen timeout haben)

ber blockierende Aufrufe wie hier sollten vermieden werden

sieht aber eher wie nen nicht blockierender Aufruf grad aus, also das myNetworkServerNotResponding() ^^ sonst macht die schleife gar ned so viel Sinn in der form ^^

Ciao ...

Das qWait hatte ich vorgeschlagen, da es laut Doku (im Gegensatz zu qSleep) nicht blockierend ist:

Waits for ms milliseconds. While waiting, events will be processed and your test will stay responsive to user interface events or network communication.

Ich arbeite viel mit externer Hardware, bei der man manchmal etwas warten muss, bis sie hochgefahren ist. Kann man natürlich alles mit Timern machen, macht aber die Programmstruktur deutlich schwerer lesbar / nachvollziehbar. Man muss z.B., wenn man mit Timern arbeitet, die Signal/Slot Architektur durch alle aufrufenden Klassen nach oben ziehen, das macht einem das Leben unnötig schwer.
QTest ausliefern müssen ist ein guter Punkt, das missfällt mir auch ... mal sehen, wie ich's mache.

Das qWait hatte ich vorgeschlagen, da es laut Doku (im Gegensatz zu qSleep) nicht blockierend ist:

richtig, sleep(qsleep) blockiert den thread
qWait unterbricht die abarbeitung dieser funktion , gibt zurueck zur messageLoop setzt nen timer, und teim call des timers kommts an die stelle wieder zurück ...
Funktioniert aber imho nur in der Testumgebung, die funktionen muessen dann auch innerhalb vom testframework aufgerufen werden ...

Ich arbeite viel mit externer Hardware

entweder synchron, also blockierende aufrufe und mehrere threads fürs handling

oder assynchron IO und mit entpsrechenden Handlern (qt: signal slots, winapi: callbacks,boost: boost asio + service bzw coroutinen, c++11: std::async + std::future)

und vom programmfluss ist assync immer schwerer nachzuvollziehen als reine lieneare 1 Thread programme. Aber daran muessen sich programmierer eh gewöhnen ^^

Ciao ...