Moving from Canoo WebTest to Selenium

[mraible]

All,

After getting Dojo's DropdownDatePicker working with both Struts and
Spring MVC, I've run into a snag:

You can no longer use Canoo WebTest to enter dates in a form.

It doesn't find the form element because HtmlUnit (the underlying
browser implementation for Canoo) doesn't understand/render Dojo's
components.

For users, workarounds include:

1. Don't write tests for entering data on forms that have required dates.
2. Don't make dates required.

Either way, it seems logical to move to Selenium for UI testing.

Thoughts?

I plan to use Selenium's Java support to write the tests, so test data
will be part of JUnit reports, which is a nice side effect. Also, if
you start Cargo + Selenium RC up in the background, you'll be able to
run tests from your IDE.

Is there anyone out there that'd like the option of WebTest or
Selenium?  It's probably possible to support both, but I'd rather not.
Selenium is simply a better solution for the problem AFAICT.

Thanks in advance for any comments.

Matt

--
http://raibledesigns.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Trent Bartlem]

On Wed, 30 May 2007 22:31:05 -0600, Matt Raible wrote
> You can no longer use Canoo WebTest to enter dates in a form.
> Is there anyone out there that'd like the option of WebTest or
> Selenium?  It's probably possible to support both, but I'd rather
> not. Selenium is simply a better solution for the problem AFAICT.

If AJAX is to be a standard feature of Appfuse, then Selenium becomes the only
practical way to test the web tier.

Do all the web frameworks Appfuse supports include AJAX libraries? (either
built-in or added by appfuse). If so, then webtest has no role to play. If
not, then maybe it's easier to force adoption by the other frameworks instead
of maintaining both canoo and selenium support.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[mraible]

On 5/30/07, Trent <[hidden email]> wrote:
> On Wed, 30 May 2007 22:31:05 -0600, Matt Raible wrote
> > You can no longer use Canoo WebTest to enter dates in a form.
> > Is there anyone out there that'd like the option of WebTest or
> > Selenium?  It's probably possible to support both, but I'd rather
> > not. Selenium is simply a better solution for the problem AFAICT.
>
> If AJAX is to be a standard feature of Appfuse, then Selenium becomes the only
> practical way to test the web tier.

True.

>
> Do all the web frameworks Appfuse supports include AJAX libraries? (either
> built-in or added by appfuse).

Struts 2 and Tapestry 4.1.x (not supported yet by AppFuse) have Dojo
baked in. JSF doesn't have anything that's standard and most of the
component libraries seem to use their own JavaScript libraries rather
than building on others. Spring MVC has nothing by default, but we
include Scriptaculous (and make it available to all frameworks).

> If so, then webtest has no role to play. If
> not, then maybe it's easier to force adoption by the other frameworks instead
> of maintaining both canoo and selenium support.

JSF has issues with WebTest currently because of all the JavaScript it uses.

FWIW, I found this Scriptaculous based datepicker that seems a little
less intrusive than Dojo.

http://www.eulerian.com/en/opensource/datepicker-prototype-scriptaculous

I got it to work with Spring MVC, but it does have some issues (shows
up on far left and doesn't go away when I click somewhere else on the
screen).

I like my Ajax effects to be of the "progressive enhancement" nature,
which AFAICT Dojo doesn't do that well. I'm more than willing to
support Dojo if that's what AppFuse users want, but in my experience
with the datepicker, it seems pretty slow. Of course, if I could
render my own input element and then add a datepicker next to it, I'd
be much happer. AFACT, the Struts datetimepicker doesn't allow you to
do this, but I could be wrong.

I guess I'm still leaning toward using Dojo for Struts and Spring MVC,
but it'd be nice if it supported progressive enhancement better so
everything still worked with JavaScript turned off.

Matt

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Sanjiv Jivan]

I favor only supporting Selenium. I see no reason to support a testing framework like Canoo which is no longer a web testing best practice.

Sanjiv

On 5/31/07, Matt Raible <[hidden email]> wrote:

All,

After getting Dojo's DropdownDatePicker working with both Struts and
Spring MVC, I've run into a snag:

You can no longer use Canoo WebTest to enter dates in a form.

It doesn't find the form element because HtmlUnit (the underlying
browser implementation for Canoo) doesn't understand/render Dojo's
components.

For users, workarounds include:

1. Don't write tests for entering data on forms that have required dates.
2. Don't make dates required.

Either way, it seems logical to move to Selenium for UI testing.

Thoughts?

I plan to use Selenium's Java support to write the tests, so test data
will be part of JUnit reports, which is a nice side effect. Also, if
you start Cargo + Selenium RC up in the background, you'll be able to
run tests from your IDE.

Is there anyone out there that'd like the option of WebTest or
Selenium?  It's probably possible to support both, but I'd rather not.
Selenium is simply a better solution for the problem AFAICT.

Thanks in advance for any comments.

Matt

--
http://raibledesigns.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[mraible]

I guess the hard part if figuring out how to do it. With Canoo
WebTest, it was easy enough to use svn:externals to pull in the
web-tests.xml (as well as login.xml and config.xml) from the
src/test/resources directory of each web module.

If we want to allow the same setup for Selenium, we'd likely put the
files in src/test/java/org/appfuse/webapp/selenium (or something
similar).  We could use svn:externals to pull these into the
archetypes, but we'd have to retain the package names. For the basic
archetypes, Maven will rename the package names, but not for the
modular archetypes, so it seems to make better sense to hard-code
these.

Of course, if Maven can run tests in a JAR file, that might be a good
solution (but it doesn't do much for IDE integration).

On a related note, does anyone have any thoughts about an
appfuse-junit dependency that includes all the Base*TestCase classes
and dependencies? We'll probably eventually need to do this if we want
to support TestNG and allow users to use JUnit. Then again, it's
probably best to switch whole-heartedly and not support multiple
testing frameworks.

Matt

On 5/31/07, Sanjiv Jivan <[hidden email]> wrote:

> I favor only supporting Selenium. I see no reason to support a testing
> framework like Canoo which is no longer a web testing best practice.
>
> Sanjiv
>
>
> On 5/31/07, Matt Raible <[hidden email]> wrote:
> >
> > All,
> >
> > After getting Dojo's DropdownDatePicker working with both Struts and
> > Spring MVC, I've run into a snag:
> >
> > You can no longer use Canoo WebTest to enter dates in a form.
> >
> > It doesn't find the form element because HtmlUnit (the underlying
> > browser implementation for Canoo) doesn't understand/render Dojo's
> > components.
> >
> > For users, workarounds include:
> >
> > 1. Don't write tests for entering data on forms that have required dates.
> > 2. Don't make dates required.
> >
> > Either way, it seems logical to move to Selenium for UI testing.
> >
> > Thoughts?
> >
> > I plan to use Selenium's Java support to write the tests, so test data
> > will be part of JUnit reports, which is a nice side effect. Also, if
> > you start Cargo + Selenium RC up in the background, you'll be able to
> > run tests from your IDE.
> >
> > Is there anyone out there that'd like the option of WebTest or
> > Selenium?  It's probably possible to support both, but I'd rather not.
> > Selenium is simply a better solution for the problem AFAICT.
> >
> > Thanks in advance for any comments.
> >
> > Matt
> >
> > --
> > http://raibledesigns.com
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>

--
http://raibledesigns.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[GojiraDeMonstah]

I really really like TestNG.

Call me a sissy, but the color-coded GUI is infinitely preferable to squinting at a command line.

Also being able to assign methods of the test classes to groups is really nice when you're working with one "silo" of functionality and need to run multiple methods across multiple tests but don't want to run everything.

The depends-on parameter is sweet too, if something basic like your dao is null you don't spend a minute and half watching all the downstream methods throw exceptions.

Perhaps some of this is just candy, but if it makes testing less painful and consequently you write better, more thorough tests, more often, it's a plus.

My 2 cents.

Jason

On 5/31/07, Matt Raible <[hidden email]> wrote:

I guess the hard part if figuring out how to do it. With Canoo
WebTest, it was easy enough to use svn:externals to pull in the
web-tests.xml (as well as login.xml and config.xml) from the
src/test/resources directory of each web module.

If we want to allow the same setup for Selenium, we'd likely put the
files in src/test/java/org/appfuse/webapp/selenium (or something
similar).  We could use svn:externals to pull these into the
archetypes, but we'd have to retain the package names. For the basic
archetypes, Maven will rename the package names, but not for the
modular archetypes, so it seems to make better sense to hard-code
these.

Of course, if Maven can run tests in a JAR file, that might be a good
solution (but it doesn't do much for IDE integration).

On a related note, does anyone have any thoughts about an
appfuse-junit dependency that includes all the Base*TestCase classes
and dependencies? We'll probably eventually need to do this if we want
to support TestNG and allow users to use JUnit. Then again, it's
probably best to switch whole-heartedly and not support multiple
testing frameworks.

Matt

On 5/31/07, Sanjiv Jivan <[hidden email]> wrote:

> I favor only supporting Selenium. I see no reason to support a testing
> framework like Canoo which is no longer a web testing best practice.
>
> Sanjiv
>
>
> On 5/31/07, Matt Raible <[hidden email]> wrote:
> >
> > All,
> >
> > After getting Dojo's DropdownDatePicker working with both Struts and
> > Spring MVC, I've run into a snag:
> >
> > You can no longer use Canoo WebTest to enter dates in a form.
> >
> > It doesn't find the form element because HtmlUnit (the underlying
> > browser implementation for Canoo) doesn't understand/render Dojo's
> > components.
> >
> > For users, workarounds include:
> >
> > 1. Don't write tests for entering data on forms that have required dates.
> > 2. Don't make dates required.
> >
> > Either way, it seems logical to move to Selenium for UI testing.
> >
> > Thoughts?
> >
> > I plan to use Selenium's Java support to write the tests, so test data
> > will be part of JUnit reports, which is a nice side effect. Also, if
> > you start Cargo + Selenium RC up in the background, you'll be able to
> > run tests from your IDE.
> >

> > Is there anyone out there that'd like the option of WebTest or

> > Selenium?  It's probably possible to support both, but I'd rather not.
> > Selenium is simply a better solution for the problem AFAICT.
> >
> > Thanks in advance for any comments.
> >
> > Matt
> >
> > --
> > http://raibledesigns.com
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> [hidden email]

> > For additional commands, e-mail: [hidden email]
> >
> >
>
>


--
http://raibledesigns.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[melinate]

sissy...


just kidding :)

Nathan

----- Original Message -----
From: "Jason Brice" <[hidden email]>
To: [hidden email]
Sent: Thursday, May 31, 2007 1:42:33 PM (GMT-0800) America/Los_Angeles
Subject: Re: [appfuse-user] Re: [appfuse-dev] Moving from Canoo WebTest to Selenium

I really really like TestNG.

Call me a sissy, but the color-coded GUI is infinitely preferable to squinting at a command line.

Also being able to assign methods of the test classes to groups is really nice when you're working with one "silo" of functionality and need to run multiple methods across multiple tests but don't want to run everything.

The depends-on parameter is sweet too, if something basic like your dao is null you don't spend a minute and half watching all the downstream methods throw exceptions.

Perhaps some of this is just candy, but if it makes testing less painful and consequently you write better, more thorough tests, more often, it's a plus.

My 2 cents.

Jason



On 5/31/07 , Matt Raible < [hidden email] > wrote:

I guess the hard part if figuring out how to do it. With Canoo
WebTest, it was easy enough to use svn:externals to pull in the
web-tests.xml (as well as login.xml and config.xml) from the
src/test/resources directory of each web module.

If we want to allow the same setup for Selenium, we'd likely put the
files in src/test/java/org/appfuse/webapp/selenium (or something
similar). We could use svn:externals to pull these into the
archetypes, but we'd have to retain the package names. For the basic
archetypes, Maven will rename the package names, but not for the
modular archetypes, so it seems to make better sense to hard-code
these.

Of course, if Maven can run tests in a JAR file, that might be a good
solution (but it doesn't do much for IDE integration).

On a related note, does anyone have any thoughts about an
appfuse-junit dependency that includes all the Base*TestCase classes
and dependencies? We'll probably eventually need to do this if we want
to support TestNG and allow users to use JUnit. Then again, it's
probably best to switch whole-heartedly and not support multiple
testing frameworks.

Matt

On 5/31/07 , Sanjiv Jivan < [hidden email] > wrote:

> I favor only supporting Selenium. I see no reason to support a testing
> framework like Canoo which is no longer a web testing best practice.
>
> Sanjiv
>
>
> On 5/31/07 , Matt Raible < [hidden email] > wrote:
> >
> > All,
> >
> > After getting Dojo's DropdownDatePicker working with both Struts and
> > Spring MVC, I've run into a snag:
> >
> > You can no longer use Canoo WebTest to enter dates in a form.
> >
> > It doesn't find the form element because HtmlUnit (the underlying
> > browser implementation for Canoo) doesn't understand/render Dojo's
> > components.
> >
> > For users, workarounds include:
> >
> > 1. Don't write tests for entering data on forms that have required dates.
> > 2. Don't make dates required.
> >
> > Either way, it seems logical to move to Selenium for UI testing.
> >
> > Thoughts?
> >
> > I plan to use Selenium's Java support to write the tests, so test data
> > will be part of JUnit reports, which is a nice side effect. Also, if
> > you start Cargo + Selenium RC up in the background, you'll be able to
> > run tests from your IDE.
> >
> > Is there anyone out there that'd like the option of WebTest or
> > Selenium? It's probably possible to support both, but I'd rather not.
> > Selenium is simply a better solution for the problem AFAICT.
> >
> > Thanks in advance for any comments.
> >
> > Matt
> >
> > --
> > http://raibledesigns.com 
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>

--
http://raibledesigns.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]