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

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

Very good points indeed! I hadn't thought of that
approach. It seems jfcUnit, Abbot, and Jemmy all
support the ability to extend JUnit in some manner. As
such, I would guess Marathon does, like you said, so
at least the APIs I will use are covered in that
respect, and more so could probably be wrapped to
support JUnit instead of a separate new framework!
Right on, thanks for pointing that out.

Now I have a question in that, adding a JPanel UI
control panel like I wanted to do... do you think a
good approach is to go by the JUnit TestCase class?
Should I even bother with an interface? I would
generally think end users want to group their tests
into functional areas, and really don't care if they
are running Jemmy, jfcUnit, Marathon, etc tests. For
the most part nobody will often use more than one
library. My specific need as I said is that we have
existing test cases, need to get started on new ones
but ultimately want to look at using Marathon down the
road IF it will continue to invest development into a
better tool than the rest, of which I am happy to
participate where I can, such as the eclipse plugin,
IntelliJ plugin, etc.

In fact, now that I think about it, my control panel
that I want to create to be added to an application so
dev/qa can quickly start recording test scripts, play
them back, as well as play back coded scripts I
believe would be a good fit in the IDE as well. If I
can soon get a basic UI control panel in place that
can start/stop recording of the various frameworks,
execute specific scripts or groups of them (or all),
and so forth, we may be closer to an eclipse/IDEA
plugin as well.

My one thought is we need to still create a simple
interface of sorts to break out the common start/stop
recording of scripts/events, and playback scripts.
Does that make sense?

--- Dakshinamurthy K <kd...@su...> wrote:
> Dear Kevin,
> 
> The common thread in all these seems to be the test.
> Since, JUnit is well
> structured and more or less a standard I suggest
> developing wrappers for all
> to convert each testcase into a JUnit test case.
> Marathon already has a
> class called TestCreator that returns a TestSuite
> from the top-level test
> tree. Each JFCUnit testcase is a JUnit testcase.
> Providing a harness to run
> all tests similar to JUnit swingUI should not be a
> problem once this is
> done.
> 
> The solution you suggested looks a little
> complicated and this is the
> minimum that seems to work.
> 
> Thanks and Regards
> KD
> 
> 
> 
>
-------------------------------------------------------
> This SF.Net email is sponsored by The 2004
> JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's
> Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center
> in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf
> Priority Code NWMGYKND
> _______________________________________________
> Marathonman-devel mailing list
> Mar...@li...
>
https://lists.sourceforge.net/lists/listinfo/marathonman-devel
> 



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