| Trolltech Home | Qt-interest Home | Recent Threads | All Threads | Author | Date | |
| All threads index page 6 | |
Hello, I want to create unit-tests for signals and slots. Aim is to test whether on emitting a signal the respective slot is called or not. So the test case would be: If signal sig_x is connected to slot_x. I want to test whether emitting the sig_x the slot_y is called. Note: We should not alter our source code. We can only make changes in our test-source. Thanks, Manjeet -- [ signature omitted ]
Hi, > I want to create unit-tests for signals and slots. Aim is to test whether on > emitting a signal the respective slot is called or not. > > So the test case would be: > If signal sig_x is connected to slot_x. > I want to test whether emitting the sig_x the slot_y is called. You probably mean slot_x in last line of slot_y in teh mine before it? But why would you want to test this? If signal sig_x is connected to slot_y, then when emitting sig_x, slot_y will be called. You shouldn't need to test that. What is the test supposed to test exactly? -- [ signature omitted ]
> You probably mean slot_x in last line of slot_y in teh mine before it? Yes. > But why would you want to test this? If signal sig_x is connected to > slot_y, then when emitting sig_x, slot_y will be called. You shouldn't > need to test that. Say the complexity of project increases. Adding new features may break the old code. Every time after adding a new feature we run these tests and make sure that the old features are fine. This is the idea of unit testing. Here in this case, unit is the signal slot connection and we want to test it. I just want to test that emitting a signal calls the respective connected slot. Best regards, Manjeet Dahiya "Dimitri" <dimitri@xxxxxxxxxxxxx> wrote in message news:fg7r0f$vqj$1@xxxxxxxxxxxxxxxxxxxxx > Hi, > >> I want to create unit-tests for signals and slots. Aim is to test whether >> on emitting a signal the respective slot is called or not. >> >> So the test case would be: >> If signal sig_x is connected to slot_x. >> I want to test whether emitting the sig_x the slot_y is called. > > You probably mean slot_x in last line of slot_y in teh mine before it? Yes. > > But why would you want to test this? If signal sig_x is connected to > slot_y, then when emitting sig_x, slot_y will be called. You shouldn't > need to test that. > > What is the test supposed to test exactly? > > -- > Dimitri -- [ signature omitted ]
Hi, > I just want to test that emitting a signal calls the respective connected > slot. I still don't understand. Emitting a signal *will* call the respective connected slot. Why test that? What are you after exactly? I guess my problem is that I don't understand what is the "respective connected slot" of a signal. -- [ signature omitted ]
Hi, > I still don't understand. Emitting a signal *will* call the respective > connected slot. Why test that? What are you after exactly? Unit testing. Please read about it, you will know. http://c2.com/cgi/wiki?UnitTest Manjeet Dahiya "Dimitri" <dimitri@xxxxxxxxxxxxx> wrote in message news:fg9743$d5k$1@xxxxxxxxxxxxxxxxxxxxx > Hi, > >> I just want to test that emitting a signal calls the respective connected >> slot. > > I still don't understand. Emitting a signal *will* call the respective > connected slot. Why test that? What are you after exactly? > > I guess my problem is that I don't understand what is the "respective > connected slot" of a signal. > > -- > Dimitri -- [ signature omitted ]
On onsdag den 31. Oktober 2007, Manjeet Dahiya wrote: > Hi, > > > I still don't understand. Emitting a signal *will* call the respective > > connected slot. Why test that? What are you after exactly? > > Unit testing. > Please read about it, you will know. http://c2.com/cgi/wiki?UnitTest Treating people who want to help like fools is a sure way to be ignored from now on. Bo. > "Dimitri" <dimitri@xxxxxxxxxxxxx> wrote in message > news:fg9743$d5k$1@xxxxxxxxxxxxxxxxxxxxx > > > Hi, > > > >> I just want to test that emitting a signal calls the respective > >> connected slot. > > > > I still don't understand. Emitting a signal *will* call the respective > > connected slot. Why test that? What are you after exactly? > > > > I guess my problem is that I don't understand what is the "respective > > connected slot" of a signal. > > > > -- > > Dimitri > > -- > To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with > "unsubscribe" in the subject or the body. List archive and information: > http://lists.trolltech.com/qt-interest/ -- [ signature omitted ]
If a failed connect triggers a qWarning, then it should be possible to catch it using a custom messagehandler, no? That message handler could easily be installed in your unit test and then removed again afterwards. - Thomas 2007/10/31, Manjeet Dahiya <manjeetdahiya@xxxxxxxxx>: > Hi, > > > I still don't understand. Emitting a signal *will* call the respective > > connected slot. Why test that? What are you after exactly? > > Unit testing. > Please read about it, you will know. http://c2.com/cgi/wiki?UnitTest > > Manjeet Dahiya > > > "Dimitri" <dimitri@xxxxxxxxxxxxx> wrote in message > news:fg9743$d5k$1@xxxxxxxxxxxxxxxxxxxxx > > Hi, > > > >> I just want to test that emitting a signal calls the respective connected > >> slot. > > > > I still don't understand. Emitting a signal *will* call the respective > > connected slot. Why test that? What are you after exactly? > > > > I guess my problem is that I don't understand what is the "respective > > connected slot" of a signal. > > > > -- > > Dimitri > > > -- > To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with "unsubscribe" in the subject or the body. > List archive and information: http://lists.trolltech.com/qt-interest/ > > -- [ signature omitted ]
On onsdag den 31. Oktober 2007, Thomas Dähling wrote: > If a failed connect triggers a qWarning, then it should be possible to > catch it using a custom messagehandler, no? Correct, but qWarnings might come for other reasons too. You can't hijack those just to catch connect failures. > That message handler could easily be installed in your unit test and > then removed again afterwards. Then the solution with a simple check whether or not the connect failed is much simpler. Bo. > 2007/10/31, Manjeet Dahiya <manjeetdahiya@xxxxxxxxx>: > > Hi, > > > > > I still don't understand. Emitting a signal *will* call the respective > > > connected slot. Why test that? What are you after exactly? > > > > Unit testing. > > Please read about it, you will know. http://c2.com/cgi/wiki?UnitTest > > > > Manjeet Dahiya > > > > > > "Dimitri" <dimitri@xxxxxxxxxxxxx> wrote in message > > news:fg9743$d5k$1@xxxxxxxxxxxxxxxxxxxxx > > > > > Hi, > > > > > >> I just want to test that emitting a signal calls the respective > > >> connected slot. > > > > > > I still don't understand. Emitting a signal *will* call the respective > > > connected slot. Why test that? What are you after exactly? > > > > > > I guess my problem is that I don't understand what is the "respective > > > connected slot" of a signal. > > > > > > -- > > > Dimitri > > > > -- > > To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with > > "unsubscribe" in the subject or the body. List archive and information: > > http://lists.trolltech.com/qt-interest/ > > -- > To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with > "unsubscribe" in the subject or the body. List archive and information: > http://lists.trolltech.com/qt-interest/ -- [ signature omitted ]
Em Wednesday 31 October 2007 11:06:00 Bo Thorsen escreveu: > > If a failed connect triggers a qWarning, then it should be possible to > > catch it using a custom messagehandler, no? > > Correct, but qWarnings might come for other reasons too. You can't hijack > those just to catch connect failures. No, not really. A correctly-running application should produce no warnings. Printing a qWarning during normal execution indicates a bug in your code somewhere. -- [ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.
Manjeet Dahiya wrote: >> You probably mean slot_x in last line of slot_y in teh mine before it? > >Yes. > >> But why would you want to test this? If signal sig_x is connected to >> slot_y, then when emitting sig_x, slot_y will be called. You shouldn't >> need to test that. > >Say the complexity of project increases. Adding new features may break > the old code. Every time after adding a new feature we run these tests > and make sure that the old features are fine. This is the idea of unit > testing. Here in this case, unit is the signal slot connection and we > want to test it. > >I just want to test that emitting a signal calls the respective > connected slot. I believe you're trying to test it in a far too low level. Instead of trying to test if a signal emission calls a slot, you can test that if the event that triggers the signal emission happens, the side-effect of the slot happens too. -- [ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.
> I believe you're trying to test it in a far too low level. Yes. True. > Instead of trying to test if a signal emission calls a slot, you can test > that if the event that triggers the signal emission happens, the > side-effect of the slot happens too. This won't test the *connection* and developer should not test whether triggering an event results in signal emission, because that code is written by Qt. It's like a contract/assumption that above thing should work. But the *connections* are done by the developer. There are chances that connections might be worng. A signal might be connected to a wrong slot. Thats why we should write unit tests for connections. Please let me know if I'm not clear. Thanks, Manjeet Dahiya "Thiago Macieira" <thiago.macieira@xxxxxxxxxxxxx> wrote in message news:200710310835.12319.thiago.macieira@xxxxxxxxxxxxxxxx -- [ signature omitted ]
Em Wednesday 31 October 2007 10:06:46 Manjeet Dahiya escreveu: > This won't test the *connection* and developer should not test whether > triggering an event results in signal emission, because that code is > written by Qt. It's like a contract/assumption that above thing should > work. > > But the *connections* are done by the developer. There are chances that > connections might be worng. A signal might be connected to a wrong slot. > Thats why we should write unit tests for connections. > > Please let me know if I'm not clear. You're not clear. I see no point in testing if a signal is connected to a slot. Signals change, code changes, etc. For instance, you could decide to intercept the signal and re-emit another signal -- i.e., an indirect connection. The flow of the program is still the same, but there's no signal-slot connection anymore. But I do see the point in verifying that a signal emission produces a given effect. -- [ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.
On tirsdag den 30. Oktober 2007, Manjeet Dahiya wrote: > Hello, > > I want to create unit-tests for signals and slots. Aim is to test whether > on emitting a signal the respective slot is called or not. > > So the test case would be: > If signal sig_x is connected to slot_x. > I want to test whether emitting the sig_x the slot_y is called. > > Note: We should not alter our source code. We can only make changes in our > test-source. I think you're trying to do the wrong thing here. Instead of testing this, you should test if the connects fail. Do something like this: if (!connect(...)) crash(); Put this in a bunch of global functions, and call those instead of calling connect() directly. Trolls: What we really need is a way to make connect failures a lot more visible. A simple qWarning is not enough. You should think about either setting a flag that can do an abort (which will allow you to catch it in the debugger) or a connect fail handler. Bo. -- [ signature omitted ]