Hi Eric,

Have you looked into using 'Squish for Java' from Froglogic? It works
like Abbot, but is much more mature as a product. I have just begun
using it here in Ericsson and it is a great tool. It is the only tool
that is better than XRunner for us (on Solaris - works on all
platforms though). You should certainly have a look... (email the
company for an evaluation license)

http://www.froglogic.com/pg?id=Products&category=squish&sub=editions&subsub=java



--- In java-gui-testing@yahoogroups.com, "Eric Kolotyluk" <eric@...>
wrote:
>
> --- In java-gui-testing@yahoogroups.com, David Herron <davidh@>
> wrote:
> >
> >
> > Interesting idea .. but...
> >
> > The email address I'm using is not my work address @ sun. As one
> of the
> > authors of the Robot class let me mention one of the policy
> decisions we
> > made at that time. I don't know if the current AWT/Swing team
> feels this
> > way, but at the time we put in Robot we didn't want to make any
> > predetermined policy decisions about how testing would be
> accomplished.
> > For example we could have embedded into AWT/Swing something akin
> to Jemmy,
> > and by doing so it might have headed off the inventiveness in the
> public
> > who have gone on to develop alternative tools like MarathonMan or
> Abbot.
> > That's why Robot is so minimalized, we wanted to provide the
> bottom level
> > rudiments of test automation and allow the public to build on that
> in
> > whatever way they saw best.
>
> That's a very good principle to follow. I think I need to become
> more familiar with the Robot class. At first glance it does not
> offer the higher level of UI stimulus I'm looking for (i.e. button
> press), but as you said, it's something to build upon.
>
> >
> > For your idea ...
> >
> > Maybe I don't understand the word "test harness", but to my eye
> what
> > you've described is more like Observability. The ability to
> observe some
> > of the system innards. To my understanding a "test harness" knows
> about a
> > set of test scenarios that can be run, and runs them one at a time
> in
> > sequence, and records the status of each scenario. For a GUI
> test, the
> > scenario is a series of events that are squirted into the
> application
> > along with verification steps during the scenario execution that
> make sure
> > the application is behaving right.
> >
> > I'm thinking there's probably already a way to construct an
> observability
> > system for Swing. e.g. JMX or dtrace?
>
> When I was in a test team at Motorola we referred to the thing that
> ran the automated test cases/suites as the "Test System" and
> the "Test Harness" was the piece between the Test System and the
> Unit Under Test. In fact I would say observability is a very
> important part of a Test Harness, as well as stimulating Unit Under
> Test. For example, I would view Costello as the Test System and
> Abbot as the Test Harness. Anyway, different places may use similar
> terms differently, but that why I saw SwATH as a "Harness".
>
> In particular (to me), the Test Harness simulates the external
> environment of the Unit Under Test, and the Test System drives the
> Unit Under Test via the Test Harness.
>
> >
> > Also I once implemented an some code that would attach to every
> listener
> > method in every GUI component and print data on every execution of
> every
> > listener method. Maybe you could write a similar thing which
> hooked up to
> > all bean properties of all GUI components in the application, and
> printed
> > data on every change of each bean property.
>
> I don't want to have to go to that much work. I don't know that it's
> enough to attach to every listener. Also, another important feature
> I want is to be able stimulate the UI at a higher level than the
> Robot class allows.
>
> >
> > One level of validating the GUI is working properly is to verify
> the logic
> > is behaving right. Are the right methods being called? Do the
> component
> > values contain the right things? That's what you'd be able to do
> by
> > tracking the component attributes like you describe.
>
> SwATH wouldn't directly be able to test if the right methods are
> being called, only that the UI contained the right values and
> exhibited the correct behavior.
>
> >
> > Would this catch errors in the business logic of the application?
>
> Yes, that is mainly what the intent is.
>
> I only just now became aware of Abbot and Costello which seems very
> similar to what I want (but in a very different way than I
> imagined). However, I'd have to spend more time with them to
> determine if they do what I really want. If they don't I'll revisit
> the SwATH idea or try to discuss features I'd like to see in other
> test systems.
>
> One advantage of SwATH over Costello is that the Test System could
> run on a different system. It looks to me like Abbot and Costello
> need to run on the same system as the Unit Under Test. I'm also
> concerned about how labor intensive it is to setup and use Abbot and
> Costello.
>
> Up until now all of our GUI Unit Testing has been manual. I'd like
> to better understand the cost trade-offs between manual testing of
> the GUI and writing test cases in Abbot, and test suites in Costello.
>
> >
> > Would this catch rendering errors in the application? Rendering
> errors
> > are particularly tricky to catch..AND.. are very expensive to test
> because
> > they so often must be manually verified.
>
> No, SwATH would definately not catch rendering errors. That is a
> whole other class of problem that products like Redstone's Eggplant
> are designed to deal with. I ruled out using Eggplant because it
> looks too labor intensive and does not look resilient enough to
> changes in the UI.
>
> I think there will always be some level of testing that just
> requires people to perform.
>
> >
> > - David Herron
> >
>
> Anyway, I really appreciate the feedback, it's given me a lot of
> useful things to think about and go and explore.
>
> Cheers, Eric
>