One thing that I might have blurred the lines on is that there are
basically 2 things being proposed here with respect to TestGen4Web.
#1 - The ability to easily create test scripts for cases that
can only be proven and solved via a deployed app (and
without cactus)
#2 - A set of scripts (that happen to be executed just like #1,
yet serve a little different purpose) that recursively
run through the cookbook links and assert success on the
page after every click.
While the existing cookbook pages usually offer some kind of
interactivity (enter some data and see it work differently for
different values), the new pages that demonstrate the taglibs (or
test them, depending on your purpose) would be required to show some
kind of success message that can be asserted. That value should not
appear if the test fails. The success message will need to be
consistent if the tests are to be recursive. Meaning that adding new
tests (recipes) to an existing page (chapter) would only require that
a new description and link be added and when clicked on will end up
showing a page where the text could be asserted. Again, that applies
to the pages that test (and demonstrate) taglibs.
So, to mentally reorg the cookbook. Instead of this:
--------------
Simple Form using ActionForm Execute <- link that gets
clicked and tested
Simple Form using DynaActionForm Execute <- same
Select and Options tags Execute <- same
...
(and on down the page)
...
--------------
We might have a Table of contents as an index that links to pages
like the one above.
If no one objects, I'll proceed on it.
--
James Mitchell
On Apr 28, 2006, at 11:36 PM, James Mitchell wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
