GUI tests

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

GUI tests

Bill Schwab-2
Hello all,

I saw the following on the Squeak mailing list, and thought it might be of
interest here as well:

===============================
I've had good results by testing at a slightly higher level. Instead of
simulating mouse-clicks I call methods on the morph that would result from
clicks in the appropriate places. To put it another way, I trust Morphic to
process clicks, and just test that the GUI responds to them correctly.

Monticello has a good example of this in MCSnapshotBrowserTest. It does
things like select a class and assert that the correct method categories
appear or select a method and assert that the method source appears in the
text pane.

I've done this sort of thing in a few other places (unreleased code) and
occasionally think about factoring it out into a Morphic testing framework,
but it's so simple that there's almost no point.
===============================

The URL for the post is:

  http://groups.yahoo.com/group/squeak/message/74417

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: GUI tests

Blair McGlashan
You wrote in message news:br2oft$25f1vn$[hidden email]...
> Hello all,
>
> I saw the following on the Squeak mailing list, and thought it might be of
> interest here as well:
>
> ===============================
> I've had good results by testing at a slightly higher level. Instead of
> simulating mouse-clicks I call methods on the morph that would result from
> clicks in the appropriate places. To put it another way, I trust Morphic
to
> process clicks, and just test that the GUI responds to them correctly.
>
> Monticello has a good example of this in MCSnapshotBrowserTest. It does
> things like select a class and assert that the correct method categories
> appear or select a method and assert that the method source appears in the
> text pane.
> ...

This sounds very similar to the way we test UI components. Some further
information on this can be found in the following newsgroup posting:

http://groups.google.co.uk/groups?hl=en&lr=&ie=UTF-8&selm=bc4nhh%24f5jvh%241%40ID-50941.news.dfncis.de

Regards

Blair


Reply | Threaded
Open this post in threaded view
|

Re: GUI tests

Bill Schwab-2
Blair,

> This sounds very similar to the way we test UI components. Some further
> information on this can be found in the following newsgroup posting:

Interesting.  Any special tricks for modal dialogs?

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: GUI tests

Blair McGlashan
"Bill Schwab" <[hidden email]> wrote in message
news:br57ga$27vmc5$[hidden email]...
> Blair,
>
> > This sounds very similar to the way we test UI components. Some further
> > information on this can be found in the following newsgroup posting:
>
> Interesting.  Any special tricks for modal dialogs?
>

A couple:
1) Build the main logic in a composite presenter that can be tested
independently. Even if this doesn't make sense for the whole dialog, you can
test large pieces of it as separate components. We often find this kind of
componentisation comes in useful anyway, since it allows for reuse.
2) Open the dialog modeless (i.e. with #show rather than #showModal)

Regards

Blair