Smalltalk - Operating dialogs programmatically in VW

Author

Operating dialogs programmatically in VW

Rowan Bunning

2004-04-19, 2:32 am

I am using VW7.2. I have a test that pops-up a dialog. How can I write
an SUnit test that operates the dialog ie. enters a value or selects cancel?

Thanks in advance,
Rowan.

Sascha Doerdelmann

2004-04-20, 4:45 am

Rowan Bunning <Rowan.Bunning_@at_softwarewithstyle.com> wrote:
> I am using VW7.2. I have a test that pops-up a dialog. How can I write
> an SUnit test that operates the dialog ie. enters a value or selects cancel?

Testmentor is a unit test tool which enables you to combine GUI and
non-GUI tests and testcode:
http://www.silvermark.com/Product/s...k/vw/index.html

Cheers
Sascha

Niall Ross

2004-04-20, 5:42 pm

Dear Rowan,
[color=darkred]
cancel?

Capture the dialog object to a temp in your test method (the object should
be returned by the method you send to Dialog, or other widget class, to pop
it up; if not, look inside the implementation of that for a method that
_does_ return the object and call at a lower level, or browse the class side
of the widget for a suitable alternative method). Then browse the instance
side of Dialog (or whatever) for its setting and getting protocol. You
should have no difficulty finding methods you can send to the object that
will set or return the values you wish.

Later, you may find yourself refactoring the temp into an instance variable
of your test case. You can then capture the dialog in setUp and manipulate
it in various ways in various tests (this assumes the dialog is a major
focus of your test; if not, you may want to leave it a temp of the test
method).

FYI, there are many examples of tests manipulating widgets in John Brant's
basic Refactoring Browser tests and in the Custom Refactoring projects
tests, downloadable from http://customrefactor.sourceforge.net/ (only VW7.1
at the moment, 7.2 will be uploaded soon). Two specific example points:

1) Very occasionally dialogs are popped up deep within forked non-returning
invoking code so that that decomposing or rewriting the code to allow direct
capture is painful. One can then do a brute-force allInstances check before
and after the test that (in non-pathological conditions) will capture. I've
only once had to do this; for the example, see the capture and manipulation
of the
CompositeRefactoringChangeInspector
via
RewriteEditorReplaceTests>>getCRCInspectorsOf: aSelector in:
aFullClassName
and even more
setCRCInspectorOf: aSelector in: aFullClassName after: aBlock
and related methods in the custom refactoring tests.

2) It can be useful to integrate your model and UI tests so that the latter
subclass the former and merely drive the former by setting and reading
values in the UI instead of directly in the model. An example of this
pattern is in
DynamicRenameMethodUITest
superclass: #{Refactory.Browser.DynamicRenameMethodTest}
where the subclass has no test methods as such; it simply overrides setUp
and tearDown to open and close a UI on the superclass' model and overrides
renameAround:
so that rerunning a superclass test feeds the values to the model through
the UI instead of directly.

If your interest is commercial, not just a hobby project then, as Sascha
remarks, TestMentor from SilverMark provides widget driving point and click
capture and replay, etc., etc. for effective UI regression testing and
suchlike. David Buck's VWUnit may also be of interest (c.f. my summary of
his talk in my report of Smalltalk Solutions 2003; find the report on
www.whysmalltalk.com events and trip reports page).

HTH

Yours faithfully
Niall Ross

Randy A. Ynchausti

2004-04-21, 5:50 am

Sascha,
[color=darkred]
cancel?

Extend TestCase with code to search for the buttons on the dialog and press
one of them. You have to fork that process off on the line of code just
before the dialog opens. For example:

testSomething

self doSomeSetup.

self pushDialogButton: 'OK'. "Forks a process to press the OK button"
self openDialogHere

Let me know if you need more hints. I have done this and use it all the
time for unit testing.

Regards,

Randy

Sponsored Links