So, after a long winded discussion on the WW Chat line....(no need to
rehash, it's in your inbox -- or will be)... several ideas were
mentioned, and so I thought I'd throw it out there for comment.
Patrick has graciously offered to provide the Struts community with
free beer and back rubs!!!! woo hooo!!! <- ok, just kidding about
the beer. Patrick has offered us free resources for automated testing.
I'll let Patrick explain in greater detail as I'm not that familiar
with what he has to offer and I don't want to misquote.
The discussion (as you've read from the chat) originally started just
as chatter about the below plugin (TestGen4Web) and what we could do
with it to help with automated testing.
There is plenty of documentation out there for TestGen4Web, but let
me explain how this thing works and where I think we can leverage it
for our own needs. TestGen4Web is a FireFox plugin that let's you
record a session (as mentioned below). Once you push record,
everything you do is remembered and you can save the file locally
right from the toolbar. You can even load an existing script and
play it.
If you have downloaded the translator, you can generate an HttpUnit
java source from the saved .xml file that implements everything you
did with the mouse and keyboard that is a ready to run HttpUnit test
class.
For example, this is what is generated when I recorded a session for
the struts-blank application:
<?xml version='1.0' encoding='UTF-8'?>
<tg4w version="0.38.1">
<actions>
<action type="goto" refresh="true" step="0">
<xpath><![CDATA[window.location.href]]></xpath>
<value><![CDATA[http://localhost:8080/struts-blank/]]></
value>
</action>
<action type="verify-title" refresh="true" step="1">
<xpath><![CDATA[*]]></xpath>
<value><![CDATA[Struts Blank Application]]></value>
</action>
<action type="assert-text-exists" step="2">
<xpath><![CDATA[*]]></xpath>
<value><![CDATA[Welcome!]]></value>
</action>
</actions>
</tg4w>
You can see in step 0 I hit the url for the struts-blank app. Then
in step 1 the title is verified and step 2 verifies that the text
"Welcome!" is in the page. I did step 2 ("assert-text-exists") by
highlighting the Welcome! text and right click -> Assert -> Verify Text.
The same .xml file can also be used to generate a Selenium
configuration xml file that does the same test.
Currently there isn't a Maven 2 plugin for the process of translating
from xml to java and that's where I come in. What comes with
TestGen4Web is an ant build that does the job. I'm currently working
on a new Maven 2 plugin that handles this and it should be finished
by the time you read this. Configuring the test to run as part of
the build will be the tricky (Wendy? help?!?!) part. With this
plugin, you won't have to download the translator.
Like most things in Maven, you aren't forced into a directory
structure, but for this purpose I propose we do this:
struts
+ action
+ apps
+ blank
+ cookbook
+ ...
+ ...
+ TestGen4Web
+ src
+ main
+ scripts <- new (.xml) scripts go here
+ target
+ gensrc <- scripts get gen'd to here (.java)
+ classes <- the plugin would compile the test to here
(Just to be clear, the only thing we should be keeping in svn is the
xml scripts)
This plugin will generate both HttpUnit (.java) and Selenium (.xml)
sources, and this would is where Patrick's process could pick up the
Selenium config.
And so, going forward with this plugin, all we would need to do is
create a new script (e.g. blank-validate-welcome.xml) and put it
under TestGen4Web/src/main/scripts and you are done. Obviously we
would want to be consistent with script naming, personally I would
prefer that they be verbose and in the event that a new script is
needed to verify a specific bug, the bug number might also be in the
name. One other option we might consider is keeping a README.txt in
that directory if any further details are needed.
These scripts would greatly speed up the release process since it
would basically do the equivalent of about 2 or more hours of what
used to be done manually.
However, the fun doesn't stop here. I'm not sure how clear I was in
the chat log about my idea for a linear set of pages to test the
taglibs, but what I had in mind would be to extend the cookbook and
provide many more examples that demonstrate the various ways some
tags can be used.
I'm not sure if we want to go the same route as the taglib tests by
providing a test for every possible combination of attributes for
every tag and some with multiple scenarios for tags that supported
different ways to provide values for a given attribute. Whatever the
case, I'm excited about being able to add new tests that are also
directly adding to the demo apps / tutorials.
When all is said and done, when you do a full build, the tests will
be executed and a report will be generated as part of the site
documentation. But the report part hasn't been written yet.
What do you think?
--
James Mitchell
On Apr 28, 2006, at 6:13 PM, James Mitchell wrote:
Speaking of testing.....I recently came across a really cool plugin
for FireFox. It's called TestGen4Web and it let's you record and
save a browser session.
<feedback type="anticipated">
What the heck is a browser session?
</feedback>
Oh, I'm glad you asked. It is the set of step that you (as a user)
do within a browser window. You can then have the saved session
(which is in xml by the way) converted to an HttpUnit test.
https://addons.mozilla.org/firefox/1385/
--
James Mitchell
On Apr 28, 2006, at 4:06 PM, Wendy Smoak wrote:
On 3/21/06, Greg Reddin <[EMAIL PROTECTED]> wrote:
As for the test cases, I'm not very familiar with Cactus or some
other web app testing packages. So to save time, I've been testing
using a simple web application and clicking through.
...
I can also check my test app into the sandbox if it
will help. Maybe someone can go ahead and start the process of
converting them to Cactus or whatever they need to be.
Craig mentioned HtmlUnit, which we're now using with Cargo to confirm
that each Action 1 example app will at least deploy and display its
default page. If you'll check in the app you mentioned, I'll add a
simple test and you can try it out. Warning: it might require a
little rearranging for Maven 2. :)
Cactus tests are beyond me at this point, I still haven't figured out
why the ones for Struts Taglib don't work.
Thanks,
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
