[action1] Improving our tests -- long [was Re: Standalone Tiles: Status and Call for Help]

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 <greddin@...> 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: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...