I looked at that when it first came out.  It's a good article.

As the co-author of the Robot class, your description of that class was curious.

As a design consideration we purposely kept Robot small .. because we did not know how people would want to use Robot nor know the "best" way to facilitate testing of the platform.  Another reason to keep Robot small was to minimize the size impact on the platform .. that is, minimize that "bloat" criticism.  If we'd made Robot a full testing solution, can you imagine what the screams of "bloat" would be like?

Secondly, Abbot is hardly the only tool which has sprung up to offer the facilities you describe.  There's many different tools, including Abbot.  Maybe you know about this page:

http://wiki.java.net/bin/view/Javapedia/TestingGUIApplications

I see that FEST isn't listed there.  Please feel free to add a link to FEST on this page.



Alex Ruiz wrote:

Dear group members,

JavaWorld just published the article "Test-Driven GUI Development with FEST" ( http://www.javaworld.com/javaworld/jw-07-2007/jw-07-fest.html  ), written by yours truly :)

I would like to kindly ask you to take a look. Feedback is always appreciated!

Sincerely,
-Alex

Hi David,

Thank you very much for your feedback :)

I understand that the Robot class was not created specifically for testing only. Unfortunately I have seen developers still trying to use it directly to test Swing GUIs. The point I was trying to make is that if we use it directly, our tests can break easily if we make changes in layout/component size :) Now I realize I should have made the point even more clear by saying that the Robot class was not designed with testing in mind...my sincere apologies for the confusion :(

I'll write a blog entry about this...thank you for pointing this out :)

I'm aware of other excellent testing GUI frameworks besides Abbot. We have been using Abbot for some time. And we also have been using TestNG. We just wanted to use these two frameworks together. So we created a small project for that purpose. Then we started playing and we got this API (that we think is easy to use) and decided to make it to make test-framework-independent and we got into FEST. As I mentioned in the article, we didn't try to reinvent the wheel, just to make things easier :)

I truly appreciate your feedback :)

Cheers,
-Alex.





David Herron <davidh@7gen.com> wrote:

I looked at that when it first came out.  It's a good article.

As the co-author of the Robot class, your description of that class was curious.

As a design consideration we purposely kept Robot small .. because we did not know how people would want to use Robot nor know the "best" way to facilitate testing of the platform.  Another reason to keep Robot small was to minimize the size impact on the platform .. that is, minimize that "bloat" criticism.  If we'd made Robot a full testing solution, can you imagine what the screams of "bloat" would be like?

Secondly, Abbot is hardly the only tool which has sprung up to offer the facilities you describe.  There's many different tools, including Abbot.  Maybe you know about this page:

http://wiki.java.net/bin/view/Javapedia/TestingGUIApplications

I see that FEST isn't listed there.  Please feel free to add a link to FEST on this page.



Alex Ruiz wrote:

Dear group members,

JavaWorld just published the article "Test-Driven GUI Development with FEST" ( http://www.javaworld.com/javaworld/jw-07-2007/jw-07-fest.html  ), written by yours truly :)

I would like to kindly ask you to take a look. Feedback is always appreciated!

Sincerely,
-Alex

---

Need a vacation? Get great deals to amazing places on Yahoo! Travel.

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
>

I'm not saying it was not designed for testing.

We had two use cases in mind:  Supporting testing, and self-runinng demos

What I'm saying is our intent was to deliver the most useful minimum necessary to enable test automation.  It was a very careful balance between getting at the most basic level of GUI interaction, and not going beyond that, while giving enough that testers could automate their tests.

Our intent was to enable others to deliver tools built on top of Robot.

If you look at the "robogeek" blogs on both blogs.sun.com and weblogs.java.net you'll find some writings I've made describing the early history of Robot.

- David



Alex Ruiz wrote:

Hi David,

Thank you very much for your feedback :)

I understand that the Robot class was not created specifically for testing only. Unfortunately I have seen developers still trying to use it directly to test Swing GUIs. The point I was trying to make is that if we use it directly, our tests can break easily if we make changes in layout/component size :) Now I realize I should have made the point even more clear by saying that the Robot class was not designed with testing in mind...my sincere apologies for the confusion :(

I'll write a blog entry about this...thank you for pointing this out :)

I'm aware of other excellent testing GUI frameworks besides Abbot. We have been using Abbot for some time. And we also have been using TestNG. We just wanted to use these two frameworks together. So we created a small project for that purpose. Then we started playing and we got this API (that we think is easy to use) and decided to make it to make test-framework-independent and we got into FEST. As I mentioned in the article, we didn't try to reinvent the wheel, just to make things easier :)

I truly appreciate your feedback :)

Cheers,
-Alex.





David Herron <davidh@7gen.com> wrote:

I looked at that when it first came out.  It's a good article.

As the co-author of the Robot class, your description of that class was curious.

As a design consideration we purposely kept Robot small .. because we did not know how people would want to use Robot nor know the "best" way to facilitate testing of the platform.  Another reason to keep Robot small was to minimize the size impact on the platform .. that is, minimize that "bloat" criticism.  If we'd made Robot a full testing solution, can you imagine what the screams of "bloat" would be like?

Secondly, Abbot is hardly the only tool which has sprung up to offer the facilities you describe.  There's many different tools, including Abbot.  Maybe you know about this page:

http://wiki.java.net/bin/view/Javapedia/TestingGUIApplications

I see that FEST isn't listed there.  Please feel free to add a link to FEST on this page.



Alex Ruiz wrote:

Dear group members,

JavaWorld just published the article "Test-Driven GUI Development with FEST" ( http://www.javaworld.com/javaworld/jw-07-2007/jw-07-fest.html  ), written by yours truly :)

I would like to kindly ask you to take a look. Feedback is always appreciated!

Sincerely,
-Alex

---

Need a vacation? Get great deals to amazing places on Yahoo! Travel.

http://www.comics.com//comics/dilbert/archive/images/dilbert2007071745828.gif

I'm not saying it was not designed for testing.

We had two use cases in mind:  Supporting testing, and self-runinng demos

What I'm saying is our intent was to deliver the most useful minimum necessary to enable test automation.  It was a very careful balance between getting at the most basic level of GUI interaction, and not going beyond that, while giving enough that testers could automate their tests.

Our intent was to enable others to deliver tools built on top of Robot.

If you look at the "robogeek" blogs on both blogs.sun.com and weblogs.java.net you'll find some writings I've made describing the early history of Robot.

- David



Alex Ruiz wrote:

Hi David,

Thank you very much for your feedback :)

I understand that the Robot class was not created specifically for testing only. Unfortunately I have seen developers still trying to use it directly to test Swing GUIs. The point I was trying to make is that if we use it directly, our tests can break easily if we make changes in layout/component size :) Now I realize I should have made the point even more clear by saying that the Robot class was not designed with testing in mind...my sincere apologies for the confusion :(

I'll write a blog entry about this...thank you for pointing this out :)

I'm aware of other excellent testing GUI frameworks besides Abbot. We have been using Abbot for some time. And we also have been using TestNG. We just wanted to use these two frameworks together. So we created a small project for that purpose. Then we started playing and we got this API (that we think is easy to use) and decided to make it to make test-framework-independent and we got into FEST. As I mentioned in the article, we didn't try to reinvent the wheel, just to make things easier :)

I truly appreciate your feedback :)

Cheers,
-Alex.





David Herron <davidh@7gen.com> wrote:

I looked at that when it first came out.  It's a good article.

As the co-author of the Robot class, your description of that class was curious.

As a design consideration we purposely kept Robot small .. because we did not know how people would want to use Robot nor know the "best" way to facilitate testing of the platform.  Another reason to keep Robot small was to minimize the size impact on the platform .. that is, minimize that "bloat" criticism.  If we'd made Robot a full testing solution, can you imagine what the screams of "bloat" would be like?

Secondly, Abbot is hardly the only tool which has sprung up to offer the facilities you describe.  There's many different tools, including Abbot.  Maybe you know about this page:

http://wiki.java.net/bin/view/Javapedia/TestingGUIApplications

I see that FEST isn't listed there.  Please feel free to add a link to FEST on this page.



Alex Ruiz wrote:

Dear group members,

JavaWorld just published the article "Test-Driven GUI Development with FEST" ( http://www.javaworld.com/javaworld/jw-07-2007/jw-07-fest.html  ), written by yours truly :)

I would like to kindly ask you to take a look. Feedback is always appreciated!

Sincerely,
-Alex

---

Need a vacation? Get great deals to amazing places on Yahoo! Travel.

Hi All,

I am new to this group. I found lot of topics which are very helpful
for ppl like me.

We are performing GUI Testing for Java Swing Application. Can anyone
let me know the information about the GUI Automation tool which works
on both Windows and Linux OS. I came to know about Eggplant but it
runs on MAC OS. Is there any alternative.

Thanks in advance

Kranthi

Hi All,

I am new to this group. I found lot of topics which are very helpful
for ppl like me.

We are performing GUI Testing for Java Swing Application. Can anyone
let me know the information about the GUI Automation tool which works
on both Windows and Linux OS. I came to know about Eggplant but it
runs on MAC OS. Is there any alternative.

Thanks in advance

Kranthi

Hi,

I've just released a new version of jDiffChaser, a GPL tool that
automatically takes and compares screenshots from the latest
production version of your swing app and the current development
version to automatically highlight changes.
We're using it for in-house projects that use swing gui and decided to
release it as an OSS months ago to share it with people that may need
such a tool. No pretension at all, this is a small simple visual
testing tool (we're still improving it) that help us finding changes
in successive versions of our graphical interfaces, and we just think
that it could help some other development teams.
The 0.5.1 version was kind of too "young", I hope this 0.8 version is
better to play with and try it. It would be cool if some of you could
test it and give us some feedback on it (about the package, the
documentation provided, the tool itself, the feature we could add to
it...).

You can find it on: http://sourceforge.net/projects/jdiffchaser

Thank you for posting feedbacks on the project forum

Thanks in advance to all for your help.

Changelog for v0.8 is:

- Full screen capture (allows multiple window applications to be
tested, window moves to be tested,...)
- Delay before screenshot (if needed, 0 sec. delay is the default one)
- No need of bsh anymore to build jDiffChaser using ant
- Fix of a focus bug when having the end-of-recording dialog displaying
- Some waiting dialogs added in order to give some better UI feedback
to the user.
- Frames and dialogs moves are handled
- Native libraries are only used when using java < 1.5 on Windows in
order to have always on top dialogs (Remote Control frame and waiting
dialogs). Consequently, OS X and probably other java-enabled platforms
are now supported through java 1.5+ (Note that we need feedback from
Linux users as we still didn't do some tests with it)
- Report details: when clicking on an image, now allows to browse the
three images of the scenario (first one, second one and diffs one)
with previous/next buttons
- Needs jdk 1.5+ to build a jar file that you can use either on hosts
running Windows with 1.4.2 java or any OS with 1.5+ java
- Fixes an OSX application restart bug that occurred when playing gui
scenarios suites
- Remote Control frame can be translucent: useful when recording full
screen applications scenarios

Hi,

Does anyone have a sugguestion of a good tool to automate testing on a
Swing/ Java webstart application?

Our application is both server and client based, the client downloads
using Java Webstart.
So we are looking for a way to record actions from the GUI which we'd
then modify to run as automated tests.

Has anyone done something similar and have pointers to good tools?

TIA
Alastair

Hi,

Does anyone have a sugguestion of a good tool to automate testing on a
Swing/ Java webstart application?

Our application is both server and client based, the client downloads
using Java Webstart.
So we are looking for a way to record actions from the GUI which we'd
then modify to run as automated tests.

Has anyone done something similar and have pointers to good tools?

TIA
Alastair

--
Eric Gavaldo - QA Manager

885, Av Doc. Julien Lefebvre
06270 Villeneuve Loubet
Office: +33 (0)4 9308 9312
Mobile: +33 (0)6 6511 5914


The information transmitted is intended only
for the person or entity to which it is addressed
and may contain confidential and/or privileged
material. Any review, retransmission, dissemination
or other use of, or taking of any action in reliance
upon, this information by persons or entities other
than the intended recipient is prohibited. If you
received this in error, please contact the sender
and delete the material from any computer.

Thanks I'll have a look at Abbot and Xstudio.

--- In java-gui-testing@yahoogroups.com, "Alastair Montgomery"
<a.montgomery@...> wrote:
>
> Thanks I'll have a look at Abbot and Xstudio.
>

Hi Alastair,

Another good alternative for Swing GUI testing is FEST (
http://fest.easytesting.org/swing/ ). Its main features are:

1. Compact API that is easy to read and write (uses fluent interfaces
to create a DSL-oriented API)
2. Supports both JUnit and TestNG
3. Embeds screenshots of failed GUI tests in both JUnit and TestNG
HTML reports

Also, please take a look at the latest SNAPSHOT release (version
0.8-SNAPSHOT) at
http://fest.googlecode.com/svn/trunk/fest/m2/repository/fest/fest-swing/0.8-SNAP\
SHOT/


The changelog for this release can be found at
http://fest.easytesting.org/swing/changes-report.html

We are in the process of updating the project's documentation before
having a full 0.8 release (next week.) This release adds new features
and is focused on making test troubleshooting easier. For example,
when a GUI component is not found, the ComponentLookupException thrown
shows a list of available components in the hierarchy. Such list uses
indentation to better understand such hierarchy.

I hope that helps.

Best regards,
-Alex.

Look cool, how about SWT support??

On Dec 28, 2007 10:22 PM, Alex Ruiz <alruiz15@...> wrote:
>
>
>
>
>
>
> --- In java-gui-testing@yahoogroups.com, "Alastair Montgomery"
>
>  <a.montgomery@...> wrote:
>  >
>  > Thanks I'll have a look at Abbot and Xstudio.
>  >
>
>  Hi Alastair,
>
>  Another good alternative for Swing GUI testing is FEST (
>  http://fest.easytesting.org/swing/ ). Its main features are:
>
>  1. Compact API that is easy to read and write (uses fluent interfaces
>  to create a DSL-oriented API)
>  2. Supports both JUnit and TestNG
>  3. Embeds screenshots of failed GUI tests in both JUnit and TestNG
>  HTML reports
>
>  Also, please take a look at the latest SNAPSHOT release (version
>  0.8-SNAPSHOT) at
>
>
http://fest.googlecode.com/svn/trunk/fest/m2/repository/fest/fest-swing/0.8-SNAP\
SHOT/
>
>  The changelog for this release can be found at
>  http://fest.easytesting.org/swing/changes-report.html
>
>  We are in the process of updating the project's documentation before
>  having a full 0.8 release (next week.) This release adds new features
>  and is focused on making test troubleshooting easier. For example,
>  when a GUI component is not found, the ComponentLookupException thrown
>  shows a list of available components in the hierarchy. Such list uses
>  indentation to better understand such hierarchy.
>
>  I hope that helps.
>
>  Best regards,
>  -Alex.
>
>
>
>

Thanks! We expect to start looking into SWT in 2008, depending on when
the 1.0 Swing version is released :)

Best regards,
-Alex

--- In java-gui-testing@yahoogroups.com, "Carfield Yim" <carfield@...>
wrote:
>
> Look cool, how about SWT support??
>
> On Dec 28, 2007 10:22 PM, Alex Ruiz <alruiz15@...> wrote:
> >
> >
> >
> >
> >
> >
> > --- In java-gui-testing@yahoogroups.com, "Alastair Montgomery"
> >
> >  <a.montgomery@> wrote:
> >  >
> >  > Thanks I'll have a look at Abbot and Xstudio.
> >  >
> >
> >  Hi Alastair,
> >
> >  Another good alternative for Swing GUI testing is FEST (
> >  http://fest.easytesting.org/swing/ ). Its main features are:
> >
> >  1. Compact API that is easy to read and write (uses fluent interfaces
> >  to create a DSL-oriented API)
> >  2. Supports both JUnit and TestNG
> >  3. Embeds screenshots of failed GUI tests in both JUnit and TestNG
> >  HTML reports
> >
> >  Also, please take a look at the latest SNAPSHOT release (version
> >  0.8-SNAPSHOT) at
> >
> >
http://fest.googlecode.com/svn/trunk/fest/m2/repository/fest/fest-swing/0.8-SNAP\
SHOT/
> >
> >  The changelog for this release can be found at
> >  http://fest.easytesting.org/swing/changes-report.html
> >
> >  We are in the process of updating the project's documentation before
> >  having a full 0.8 release (next week.) This release adds new features
> >  and is focused on making test troubleshooting easier. For example,
> >  when a GUI component is not found, the ComponentLookupException
thrown
> >  shows a list of available components in the hierarchy. Such list uses
> >  indentation to better understand such hierarchy.
> >
> >  I hope that helps.
> >
> >  Best regards,
> >  -Alex.
> >
> >
> >
> >
>

Great, I am not sure if SWT really better than swing or not, but
several big firm make the IT policy of GUI selection with SWT, we have
to use it :-)

On Dec 30, 2007 11:09 PM, Alex Ruiz <alruiz15@...> wrote:
>
>
>
>
>
>
> Thanks! We expect to start looking into SWT in 2008, depending on when
>  the 1.0 Swing version is released :)
>
>  Best regards,
>  -Alex
>
>  --- In java-gui-testing@yahoogroups.com, "Carfield Yim" <carfield@...>
>  wrote:
>  >
>  > Look cool, how about SWT support??
>  >
>  > On Dec 28, 2007 10:22 PM, Alex Ruiz <alruiz15@...> wrote:
>  > >
>  > >
>  > >
>  > >
>  > >
>  > >
>  > > --- In java-gui-testing@yahoogroups.com, "Alastair Montgomery"
>  > >
>  > > <a.montgomery@> wrote:
>  > > >
>  > > > Thanks I'll have a look at Abbot and Xstudio.
>  > > >
>  > >
>  > > Hi Alastair,
>  > >
>  > > Another good alternative for Swing GUI testing is FEST (
>  > > http://fest.easytesting.org/swing/ ). Its main features are:
>  > >
>  > > 1. Compact API that is easy to read and write (uses fluent interfaces
>  > > to create a DSL-oriented API)
>  > > 2. Supports both JUnit and TestNG
>  > > 3. Embeds screenshots of failed GUI tests in both JUnit and TestNG
>  > > HTML reports
>  > >
>  > > Also, please take a look at the latest SNAPSHOT release (version
>  > > 0.8-SNAPSHOT) at
>  > >
>  > >
>
>
http://fest.googlecode.com/svn/trunk/fest/m2/repository/fest/fest-swing/0.8-SNAP\
SHOT/
>  > >
>  > > The changelog for this release can be found at
>  > > http://fest.easytesting.org/swing/changes-report.html
>  > >
>  > > We are in the process of updating the project's documentation before
>  > > having a full 0.8 release (next week.) This release adds new features
>  > > and is focused on making test troubleshooting easier. For example,
>  > > when a GUI component is not found, the ComponentLookupException
>  thrown
>  > > shows a list of available components in the hierarchy. Such list uses
>  > > indentation to better understand such hierarchy.
>  > >
>  > > I hope that helps.
>  > >
>  > > Best regards,
>  > > -Alex.
>  > >
>  > >
>  > >
>  > >
>  >
>
>

I am now working on a GUI app migrate from awt/Swing to SWT RCP, which
means it use AWT/Swing/SWT components at the same time. Is there any
tool can autotest this kind of app? Abbot.swt?

Thanks.

We released version 3.3 of our Java GUI Testing tool Squish. It
supports testing Swing/AWT and SWT/Eclipse RCP applications on
Windows, Linux/Unix and Mac OS X.

New features include

- Support for testing applications which mix AWT/Swing and SWT/RCP

- Support for record & replay of drag'n'drop and mouse drag
operations

- Dedicated record & replay support for Eclipse GEF-based controls

- Support for record & replay of Java sub-applications which are
started from the main Java application

- Improved record & replay for interaction with tree widget handles

- Support for testing (record and replay) of Java applets via applet
viewer or embedded in a web page

- Support for testing (record and replay) of Java applications
started via Java Web Start.

- Drastically simplified setup for hooking into Java applications

For more information about Squish and the new release see
http://www.froglogic.com.

I want to use Marathon for testing a GUI and we had it working before. Now
the test cases have changed, so I had to modularize the whole Marathon
project into smaller ones. I created the new projects out of Marathon and I
got the usual folder structure (Fixtures, Modules, TestCases) and the
.project configuration file. I let Marathon create my default Fixture and
its contents are just the same as the one before. When I create a new Test
script out of Marathon (or from eclipse, or from a txt-tool) and I try to
run it or to record with Marathon, I always get an Python error:

ScriptException: NameError: default

I use the standard method at the beginning of my test scripts:
useFixture(default), and even if I let Marathon create it automatically, it
still cannot recognize 'default', although it asks me to overwrite the
existing file default.py, which tells me, the marathon.fixture.dir property
is correctly set to %marathon.project.dir%/Fixtures.

I have absolutely no idea what is wrong here and if I can't fix it, I wont
be able to use Marathon for any more testing.

Somebody has an idea?

Thx, Sergio
--
View this message in context:
http://www.nabble.com/Marathon-NameError%3A-default-tp15612875p15612875.html
Sent from the Java GUI Testing mailing list archive at Nabble.com.

Please use Marathon help forum - I generally check it out frequently
and might be able to respond faster.

That said, when configuring a project you need to give the full path
to the class name (like x.y.z.ClassName) rather than just the main
class name. In 90% of the cases, that is the reason for this error
message.

HTH.

-- KD


On Thu, Feb 21, 2008 at 8:33 PM, serdsch <sergio.weigel@...> wrote:
>
>
>
>
>
>
>
>  I want to use Marathon for testing a GUI and we had it working before. Now
>  the test cases have changed, so I had to modularize the whole Marathon
>  project into smaller ones. I created the new projects out of Marathon and I
>  got the usual folder structure (Fixtures, Modules, TestCases) and the
>  .project configuration file. I let Marathon create my default Fixture and
>  its contents are just the same as the one before. When I create a new Test
>  script out of Marathon (or from eclipse, or from a txt-tool) and I try to
>  run it or to record with Marathon, I always get an Python error:
>
>  ScriptException: NameError: default
>
>  I use the standard method at the beginning of my test scripts:
>  useFixture(default), and even if I let Marathon create it automatically, it
>  still cannot recognize 'default', although it asks me to overwrite the
>  existing file default.py, which tells me, the marathon.fixture.dir property
>  is correctly set to %marathon.project.dir%/Fixtures.
>
>  I have absolutely no idea what is wrong here and if I can't fix it, I wont
>  be able to use Marathon for any more testing.
>
>  Somebody has an idea?
>
>  Thx, Sergio
>  --
>  View this message in context:
> http://www.nabble.com/Marathon-NameError%3A-default-tp15612875p15612875.html
>  Sent from the Java GUI Testing mailing list archive at Nabble.com.
>
>



--
Dakshinamurthy Karra (http://blog.jaliansystems.com)

I know that AWT has a EventQueue,which we can use to post events into
the JVM not the OS.
But it seems that SWT doesn't has such an EventQueue. The only way to
post event is the Display.post(), which will post event into OS.

The reason I want to post event into JVM not OS is that I want to run
serveral instances of GUI application test on the same box. Is there
any other choices?

Thanks.
Tony.

Hi,

Please find the following requirement

Java Professionals with 4.5+ years exp.

Skills:  Java, JSP, HTML, Spring/Hibernate/Struts framework, Ajax, XML

Requirement : Immediate

Location : MNC, Bangalore (www.spansystems.com)

Salary : No bar

Contact: ramansiva@...

I would like to be able to validate that all of the items in a list box
correspond to a given list of the items.
Do any test tools (Abbot, QuickTestPro, other ?) provide an easy way to
do this ?  Or will I need to select each item and then
compare it to the corresponding item in my requirements list ?

Ideally, I'd also like some way of automatically generating any
discrepancies
for example:
"the value 'blue' is in list 'colors', but not in list 'options' "
"the value 'teal' is in list 'options', but not in list 'colors' "

Thanks very much.    Curt

I don't know of these tools, but I am sure all of the tools will have
some way of doing this.

In Marathon (that I know -- http://www.marathontesting.com) you just
insert a assert_content into the script while recording the script.

-- KD

On Fri, Aug 1, 2008 at 12:30 AM, rcurthicks <rcurthicks@...> wrote:
>
> I would like to be able to validate that all of the items in a list box
> correspond to a given list of the items.
> Do any test tools (Abbot, QuickTestPro, other ?) provide an easy way to
> do this ? Or will I need to select each item and then
> compare it to the corresponding item in my requirements list ?
>
> Ideally, I'd also like some way of automatically generating any
> discrepancies
> for example:
> "the value 'blue' is in list 'colors', but not in list 'options' "
> "the value 'teal' is in list 'options', but not in list 'colors' "
>
> Thanks very much. Curt
>
>



--
Dakshinamurthy Karra (http://blog.jaliansystems.com)

Hi Curt,

You can do it with FEST (
http://fest.easytesting.org/swing ...disclaimer: I'm
the creator of FEST). Currently, FEST returns the
contents of a JList as an array of Strings:

JListFixture list = // create a JListFixture that
wraps the JList you are testing
assertThat(list.contents()).isEqualTo("one", "two",
"three").

Note: The 'assertThat' method is part of the
'Assertions' module included in FEST.

I hope that helps :)

Best regards,
-Alex


--- Dakshinamurthy Karra <technovator@...>
wrote:

> I don't know of these tools, but I am sure all of
> the tools will have
> some way of doing this.
>
> In Marathon (that I know --
> http://www.marathontesting.com) you just
> insert a assert_content into the script while
> recording the script.
>
> -- KD
>
> On Fri, Aug 1, 2008 at 12:30 AM, rcurthicks
> <rcurthicks@...> wrote:
> >
> > I would like to be able to validate that all of
> the items in a list box
> > correspond to a given list of the items.
> > Do any test tools (Abbot, QuickTestPro, other ?)
> provide an easy way to
> > do this ? Or will I need to select each item and
> then
> > compare it to the corresponding item in my
> requirements list ?
> >
> > Ideally, I'd also like some way of automatically
> generating any
> > discrepancies
> > for example:
> > "the value 'blue' is in list 'colors', but not in
> list 'options' "
> > "the value 'teal' is in list 'options', but not in
> list 'colors' "
> >
> > Thanks very much. Curt
> >
> >
>
>
>
> --
> Dakshinamurthy Karra (http://blog.jaliansystems.com)
>

Greetings,

It gives me pleasure to announce 2.0 stream of releases for Marathon.
Marathon is a Java/Swing GUI testing tool with an integrated editor,
recorder, debugger and player. Marathon tests are pure script code and
currently supports Jython and JRuby.

Website: http://www.marathontesting.com/Marathon.html
Downloads: http://sourceforge.net/project/platformdownload.php?group_id=46616
Discussions: http://groups.google.com/group/marathon-testing

For those of you who have seen Marathon 1.x already, these are the highlights:

1. Marathon now can record script code either in Jython or JRuby. The
option is selected at project creation time.
2. Marathon now sports an integrated debugger. You can keep
breakpoints, step through the code and use the script console to
inspect the application.
3. The editor is based on latest version of text area package from
jEdit. You can customize most of the features.

Thanks and Regards
KD

--
Dakshinamurthy Karra (http://blog.jaliansystems.com)

Hello,

I am looking around for a check list to validate the UI aspects of
swing applications. I read L&F guide lines, but something in checklist
format will be great.

A little background:

Somewhat inspired by eclipse UI test harness (when the tests are run,
each dialog is presented along with a checklist), I am working on
including similar one into Marathon. More details are available @
http://blog.marathontesting.com . By default, I am planning to include
some checklists into the distribution. Of course, the origin of the
checklist will be acknowledged.

Thanks and Regards
KD

--
Dakshinamurthy Karra
(blog: http://blog.marathontesting.com)
(daily dose: http://twitter.com/marathontesting)