[Marathonman-devel] Re: [Fwd: Marathon]

[Kevin D. <sup...@ya...>]

Hey all,

So I told my boss about Marathon, he has heard of it
and sounds interested. Our primary concern is
drag/drop. We have a TON of it.. so much so that most
of our interface is drag/drop. If Marathon can't
support drag/drop, we can't use it, that is what he
and I discussed.I know its a phase 2 item, so it may
be a while before we can use Marathon.

BUT, I have had another idea. Most likely it will
behoove us to use jfcUnit for the short term. We also
have a number of jemmy scripts in place. And
eventually, once Marathon matures enough to handle
pretty much every aspect of UI automation within
Swing, I'll no doubt want to be using that. My boss
has given me the go ahead to help contribute, but I am
sure ya'll know that I can't spend a ton of work time
working on a framework, we have a product release in a
few months and I got to get down to business
automating the UI as quickly as possible.

So my idea is this. Rather than be stuck using one
framework, I want to create a sort of test harness
JPanel/library that can be snapped in to any
dialog/window and accessed via a menu item or button
or what have you. The framework will allow for
different test frameworks to be used including jemmy,
jfcUnit and Marathon. I am only in the beginning
stages of it, so I am not entirely sure what direction
to go yet, but I believe this will allow us to
continue using the many hundreds of jemmy tests we
have, as well as start using jfcUnit for now, and once
Marathon comes up to par, move over to marathon while
not having to rewrite the jfcUnit tests..at least not
until they need to be changed.

So, about the picking your brains part... My initial
thought is an interface that each API provides a
wrapper for. Now I am not going to ask Jemmy, jfcUnit,
and others to include this wrapper. I'll provide the
wrapper. What I want to figure out is what is "common"
amongst the frameworks. My thinking is the ability to
execute a test, an ammended method can take a group of
tests and run them so you can group tests into a
functional area, for example a dialog that opens
different types of file formats you may want to create
separate tests for it, but run them all at one time if
you are the developer working on that particular UI
piece. A run all feature (especially useful after
someone updates their local copy of code from the main
branch and integrates/merges all changes). Another
feature would be record/playback of scripts. I know
jfcUnit supports this, I believe jemmy does, Abbot and
Pounder support it, and I am thinking Marathon does,
or if not will. It seems obvious to me we definitely
want to support this feature if we dont already. It
gives us a close to black-box testing, but allows us
to automate it. I am sure ya'll are well aware.

What other things should a common grouds interface
provide?

On the UI Front of this test control panel, there are
two ways I wanted to go. One would be a JPanel, ready
to be incorporated into any dialog or window. The
panel would be constructed and ready to use by anyone
complete with wrappers for at least jemmy, jfcUnit and
marathon as those I'll use. Someone that uses Abbot
can contribute an Abbot wrapper. The panel would
provide buttons, tabs or some other good looking and
easy to use UI to show tests. My thought is a two-view
approach. One is by the TYPE of test..that is jfcUnit
is a separate tree node, and below it are all the
jfcUnit tests you can run. Marathon another tree node
with all its tests below it.  The other view is by
functional area, where you can group tests into areas
you wish to test as a group. This way you can better
manage tests by placing them in groups and able to run
those groups at one time, hence my interface method of
executeGroupTests().

As for the way to identify a test, I figured let's
make it easy, a name. Since most likely a filename
would be unique, we could go that route. Or, we could
provide a meta data type of object for each test, one
that identifies a name, the location of the script (if
it is a script) or class file (if its done via code),
maybe some other specific parameters for each test. My
only concern is loading all this into memory. Knowing
that there will likely be 1000's of tests in a given
application, we surely don't want to load all this up
if most of them will never be clicked on to looked at.
Not a problem, we can provide some sort of file on
disk that describes each test meta data, and when
clicked on in the panel (however we represent it),
we'll use the meta data of the config file to locate
its info and display it. I have a kewl way of doing
this..I use xml and use an xml pull parser. It is
extremely fast and uses less memory than sax parsing,
and thus far is about as fast as text file processing,
only with the use of xml we can better make it
readable and easily modifiable with text editors.

Now, the thing is, I am definitely going to go this
route, find a way to make a test harness that can work
with different frameworks and get it working. That
I'll have done soon for an initial prototype. What I
was hoping you guys would do is provide some thoughts
on what I have just described, maybe ideas on the UI
section, or ways to handle the frameworks at a common
ground. I am sure each API has its own script file
format, some sort of header info to identify it, so
when a user clicks on a file we could open it up and
provide a way to determine the API to use. I have done
this before with my previous job for text and xml
files, fairly easy to do. The notion of grouping them
will require some extra management as I said, most
likly via xml file stored with the scripts or as part
of a test project or something.

Anyway, I would appreciate any thoughts/feedback.
Criticism is welcome, although I am thinking that this
would be a great benefit to the java test community so
I am hoping ya'll like the idea and we can make it
happen. I do not know if there is already something
like this, but I was thinking making it a stand-alone
app, as well as pluggable into any app by simply
adding the JPanel.

Look forward to hearing from ya'll.


--- Kingsley Hendrickse <kin...@ic...> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi
> 
> KD or Dan I think you're in the best position to
> answer some of Kevins
> questions as you have been doing the most
> development work.
> 
> Thanks
> Kingsley
> 
> - ---------------------------- Original Message
> ----------------------------
> Subject: Marathon
> From:    "Kevin Duffey"
> <sup...@ya...>
> Date:    Fri, June 18, 2004 7:15 am
> To:      kin...@ic...
> -
>
--------------------------------------------------------------------------
> 
> Hi,
> 
> I posted a blog on UI automation testing, and
> someone
> responded to my blog asking if I had checked out
> Marathon..was that you? Or someone else on the
> Marathon team?
> 
> Anyway, I am interested in the project, possibly, if
> it does/meets what I will need it to do.
> 
> I am looking to handle EVERY aspect of full Swing UI
> automation. Our product has a ton of drag/drop,
> trees,
> tables, input fields, buttons, combo boxes, and is
> full internationalized. On top of that, we have a
> lot
> of specialized rendering. For example, we provide a
> mapping interface that draws lines from one side to
> the other, and not always straight paths. As you
> scroll the right side, for example, the lines that
> are
> mapped on the left are redrawn diagonally as the
> right
> scrolls, if you get my drift.
> 
> So there is a HUGE amount to test. Can Marathon
> already do this? OR is it months away from being
> able
> to do this? jfcUnit is my current choice as it seems
> to be the most mature library to use for this type
> of
> testing. I will need the ability to record/playback,
> as well as write code to automate the product. It
> also
> needs to be easy to maintain, enough so that if a
> component is removed and something else added, a few
> lines of code, or a re-record of the script is done.
> It should not depend on positional or named
> components, but like jfcUnit, listen/record from the
> event que, use the Robot class if possible to
> simulate
> OS events on playback, and otherwise allow hierachal
> access to components so that components already
> coded
> dont have to all be updated with names, and so
> forth.
> 
> Now, if Marathon can already do this, or is close to
> it, you have my ears. The problem is, within a
> months
> time I need to be productive with something, showing
> results. If Marathon isn't quite up to this task,
> then
> I am afraid I wont have a lot of time to contribute.
> But if it is already able to do most of this, and
> its
> an active library, I may be able to help. Not only
> will I have a pretty robust and advanced GUI to test
> against with it, thus ensuring it handles the most
> intense UI testing, but I would be allowed to
> contribute a bit here and there AND provide
> articles/test cases to market the library even more.
> I
> have already stated that I am part of the jfcUnit
> team, although haven't done a thing yet. I am not
> locked in to it and if Marathon is a better
> alternative, I am all for it!
> 
> So fill me in, please. Let me know what it is
> capable
> of via Swing testing now, where it will be soon,
> what
> are the goals, etc.
> 
> Thanks
> 
> 
> 
> 
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail Address AutoComplete - You start. We
> finish.
> http://promotions.yahoo.com/new_mail
> 
> 
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
> 
>
iD8DBQFA0s+CZ8AEccynd5gRAhnxAKCfh8Xu08oy6RYT/c74aI+wTQdGKwCfUWzk
> k3R/ME6GVcIzhz0LrI9igJA=
> =dB6F
> -----END PGP SIGNATURE-----
> 
> 



		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail