How test Dialog UI?
Locked
 
|
CONTENTS DELETED
The author has deleted this message.
|
|
|
I had one case where a modal window was ignoring commands--it failed to open secondary windows. I fixed that by using #uiEventFor: to schedule an event for the window. A common use for #uiEventFor: would be to return data to a window for display from a forked process. In my case, everything worked as expected except that error/warning dialogs silently failed to open in only a few scenarios.
I've also seen problems were post-open instructions were simply not executed when opening a window. That is due to some in-house code that opens the window a strange way with parameters. Standard conventions were not followed that would have called the post-open code. Paul Baumann -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of VAM Sent: Monday, August 17, 2009 3:42 PM To: [hidden email] Subject: [vwnc] How test Dialog UI? Hi. I like full coverage code by tests. Nonmodal UI is easy for testing. But what you do with dialog UI? Now, at MyDialogTestCase>>setUp I send message dialogInstance>>allButOpenInterface: it's work for 80% cases. But if I have in #postOpenWith: then I don't execute. How you do it (test dialog ui)? -- View this message in context: http://www.nabble.com/How-test-Dialog-UI--tp25012924p25012924.html Sent from the VisualWorks mailing list archive at Nabble.com. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
CONTENTS DELETED
The author has deleted this message.
|
|
|
In reply to this post by vam
VAM wrote:
> Hi. > > I like full coverage code by tests. > Nonmodal UI is easy for testing. But what you do with dialog UI? > Now, at MyDialogTestCase>>setUp I send message > dialogInstance>>allButOpenInterface: > it's work for 80% cases. But if I have in #postOpenWith: then I don't > execute. > > How you do it (test dialog ui)? > including modal dialogs. David Buck Simberon Inc. www.simberon.com _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
CONTENTS DELETED
The author has deleted this message.
|
|
|
In reply to this post by vam
I don't know if I fully understand your problem. But maybe, this hint is
helpful: Applications that run embedded as SimpleDialog never execute #postOpenWith:. To provide for post-open activity you must send #postOpenBlock: to the dialog to assign a block to run after opening the dialog window. For examples in VW7.6 see methods ClassFinder>>openDialogInterface: and Store.BlessingDialog>>openDialogInterface:. Regards Holger Guhl -- Senior Consultant * Certified Scrum Master * [hidden email] Tel: +49 231 9 75 99 21 * Fax: +49 231 9 75 99 20 Georg Heeg eK Dortmund Handelsregister: Amtsgericht Dortmund A 12812 VAM schrieb: > Hi. > > I like full coverage code by tests. > Nonmodal UI is easy for testing. But what you do with dialog UI? > Now, at MyDialogTestCase>>setUp I send message > dialogInstance>>allButOpenInterface: > it's work for 80% cases. But if I have in #postOpenWith: then I don't > execute. > > How you do it (test dialog ui)? > vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
CONTENTS DELETED
The author has deleted this message.
|
|
|
In reply to this post by vam
No, there were no undesirable side effects from the fix I mentioned. I described two experiences that seemed similar to the problem you described. I understand now that you have a different kind of problem.
The real problem that you face is that a modal dialog opens while testing is in progress, and that dialog interrupts testing until clicked on. You can anticipate the dialog and queue actions that would close the dialog (as if you clicked on it yourself). You can avoid opening the dialog entirely while tests are in progress. You can implement your own dialogs. I remember that VisualAge had native OS dialogs that would suspend the image in a callout until the user responded. Those dialogs messed up any time-sensitive callin actions. The approach I took to fix that was to implement and use non-native dialogs that could be opened through a configurable "messenger" object. During testing, the dialogs would be configured to give their default response instead of opening. Paul Baumann -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of VAM Sent: Monday, August 17, 2009 5:11 PM To: [hidden email] Subject: Re: [vwnc] How test Dialog UI? Hm, my main problem with testing dialog - block testing process while dialog open. I right undestand you that you solved this problem and left secondary problems? Paul Baumann wrote: > > I had one case where a modal window was ignoring commands--it failed > to open secondary windows. I -- View this message in context: http://www.nabble.com/How-test-Dialog-UI--tp25012924p25014282.html Sent from the VisualWorks mailing list archive at Nabble.com. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by vam
Dear VAM,
I use method wrappers to run tests that will open modal dialogs. See my talk at Smalltalk Solutions 2007 for detailed discussion with code examples (download all 97Mb of the conference from the stic site to find my slides and my report with write-up of my talk). You wrap the appropriate method of the dialog with a wrapper - I usually use a ConditionalMethodWrapper - that provides the alternative behaviour you need when your test invokes it - usually some equivalent of the user clicking OK, entering some text field or whatever. (Load appropriate versions of the custom refactoring versions of the RB and its tests from the open repository - bundles Tools-Refactoring Browser and RefactoringBrowserTests with versions beginning CS... - into 7.5 to see examples. N.B. do not attempt to load a 7.5 RB version into 7.6.) Paul Baumann wrote > I remember that VisualAge had native OS dialogs that would suspend the image in a callout until the user responded. Those dialogs messed up any time-sensitive callin actions. The approach I took to fix that was to implement and use non-native dialogs that could be opened through a configurable "messenger" object. During testing, the dialogs would be configured to give their default response instead of opening. My TestUIBrowser (in the MetaTestBrowser map from http://vastgoodies.com/) addresses similar issues. Yours faithfully Niall Ross >Hi. > >I like full coverage code by tests. >Nonmodal UI is easy for testing. But what you do with dialog UI? >Now, at MyDialogTestCase>>setUp I send message >dialogInstance>>allButOpenInterface: >it's work for 80% cases. But if I have in #postOpenWith: then I don't >execute. > >How you do it (test dialog ui)? > > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
I've actually done tests that just open the dialog and then
do what's appropriate. It's a bit slow and painful, but works for a
smaller number. Basically, open it in a different thread, go grab the
current window, verify that it's the dialog, and then tell the button to
click.
At 11:53 AM 2009-08-18, Niall Ross wrote: Dear VAM, --
Alan Knight [|], Engineering Manager, Cincom Smalltalk
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Niall Ross
Dear Alan,
I had tests like that in the custom RB and still have a few that I've never retired. However they were a bit brittle: they needed time delays, and before and after state checks, to get the right dialog and over the years I repeatedly had to reset the short-but-safe delay time as the RB, its test suite and the image and VM evolved to have different characteristics. Later, I wrote wrapper tests, and rewrote some of the older ones to use wrappers, and my impression is that they were less brittle. The wrapper can work in the way you describe - it can just be a way to get the object, whose text filed you then fill and whose button you then click - though I confess I have often been lazier and just substituted returning true for opening the dialog and suchlike. Yours faithfully Niall Ross > I've actually done tests that just open the dialog and then do what's > appropriate. It's a bit slow and painful, but works for a smaller > number. Basically, open it in a different thread, go grab the current > window, verify that it's the dialog, and then tell the button to click. > > At 11:53 AM 2009-08-18, Niall Ross wrote: > >> Dear VAM, >> I use method wrappers to run tests that will open modal dialogs. >> See my talk at Smalltalk Solutions 2007 for detailed discussion with >> code examples (download all 97Mb of the conference from the stic site to >> find my slides and my report with write-up of my talk). >> >> You wrap the appropriate method of the dialog with a wrapper - I usually >> use a ConditionalMethodWrapper - that provides the alternative behaviour >> you need when your test invokes it - usually some equivalent of the user >> clicking OK, entering some text field or whatever. >> >> (Load appropriate versions of the custom refactoring versions of the RB >> and its tests from the open repository - bundles Tools-Refactoring >> Browser and RefactoringBrowserTests with versions beginning CS... - into >> 7.5 to see examples. N.B. do not attempt to load a 7.5 RB version into >> 7.6.) >> >> Paul Baumann wrote >> > I remember that VisualAge had native OS dialogs that would suspend >> the image in a callout until the user responded. Those dialogs messed >> up any time-sensitive callin actions. The approach I took to fix that >> was to implement and use non-native dialogs that could be opened >> through a configurable "messenger" object. During testing, the >> dialogs would be configured to give their default response instead of >> opening. >> >> My TestUIBrowser (in the MetaTestBrowser map from >> http://vastgoodies.com/) addresses similar issues. >> >> Yours faithfully >> Niall Ross >> >> >> >Hi. >> > >> >I like full coverage code by tests. >> >Nonmodal UI is easy for testing. But what you do with dialog UI? >> >Now, at MyDialogTestCase>>setUp I send message >> >dialogInstance>>allButOpenInterface: >> >it's work for 80% cases. But if I have in #postOpenWith: then I don't >> >execute. >> > >> >How you do it (test dialog ui)? >> > >> > >> >> >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > -- > Alan Knight [|], Engineering Manager, Cincom Smalltalk > [hidden email] > [hidden email] > http://www.cincom.com/smalltalk _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |