incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Jaquith <>
Subject Re: Selenium
Date Thu, 13 Dec 2007 06:07:25 GMT
Good points! Some replies inline...

On Dec 12, 2007, at 11:53 PM, Dirk Frederickx wrote:

> Tx Andrew.
> The first check-in of selenium tests were really a very quick first
> attempt, to check feasibility.

Understood. The tests were a very good proof-of-concept, though, and  
I'd glad you made them. The nice thing about Selenium-IDE is that it's  
ridiculously easy to rig up new tests. Let's make more!

> Some other issues :
> * there is to much copy/paste between the different test,  we need to
> find an easy way to define some common parameters (eg username,
> password, url's etc.)

One option we have is to save/translate the tests as Junit tests. One  
of Selenium-IDE export options is generated Java files, so this is  
pretty easy. Writing the tests in Java would enable us to use common  
variables, "tests scaffolding" and the like. And it would print out  
the results on the command line (Ant) or in Eclipse, which is a good  

I've preserved the tests/com.ecyrd.jspwiki.web package for this  
purpose (even though they are "hollowed out" and don't do anything).

> * i18n : the tests should preferably not check on 'english' texts but
> use the id or class attributes to check presence/absence of certain
> elements. Selenium is very powerful, we just may need to update some
> jsps with some extra new id's.
> EG check on css-class 'authenticated' iso the text (authenticated)

It's probably a good idea to check for ids or class attributes during  
tests. But I think it's still a good idea to check for specific text  
in certain cases. If we did the tests in Java, that would be really  
easy -- we could just use the standard i18n factories and match on  

> * we should also document somewhere to available users/groups of the
> different test setups.  I was trying to make a DeletePage tests but
> couldn't find the admin user/pw of the test configuration.

FYI, these are contained in a static "scaffolding" class in tests/ 
com.ecyrd.jspwiki.auth.Users. We should probably move this to the top- 
level package.

> I'm almost done porting the remaining tests also to selenium. Check-in
> in a couple of days.

Fabulous. Note that I've just checked in a significantly re-organized  
web unit test configuration. Before you get too far along, you should  
re-sync with HEAD. In particular, I moved the location of the *.html  
Selenium test files, and the contents are *slightly* different. They  
are also now "template" files that are copied at test time by Ant to  
tests/build and then executed for each of the five auth/container  
scenarios we test.

It probably sounds complicated, but it's really not. Just download the  
changes; try running the Ant 'webtests' script; it should be pretty  
obvious how everything works.


> dirk
> On 12/13/07, Andrew Jaquith <> wrote:
>> Janne -- I have solved just about all of these issues, and am  
>> readying
>> a rather large checkin. I've got things totally automated in Ant.  
>> I'll
>> check it in tonight.
>> Andy
>> On Dec 12, 2007, at 6:21 PM, Janne Jalkanen wrote:
>>> Hi ho folks!
>>> I have been looking at the Selenium tests, and I have to say that
>>> I'm impressed.  I had some initial problems setting up (for some
>>> reason, Eclipse does not refresh new directories from CVS properly),
>>> but when I got it running, it looks really nice and usable.
>>> Unfortunately, I managed only to get two tests working, the rest of
>>> them were failing.  I noticed a few things which are probably of  
>>> note.
>>> 1) The tests assume that JSPWiki is installed in JSPWiki-pipo.  Any
>>> chance to get this somehow configurable?
>>> 2) Make sure your browser is set to default to English, or else your
>>> tests will fail in strange ways :-)
>>> 3) Use IP address, not "localhost" to access the wiki ( !=
>>> localhost, according to Selenium). Should probably be documented.
>>> 4) AnonymousViewImage does not seem to work at all (no test result)
>>> 5) The set of pages that the tests need should probably be
>>> documented somewhere
>>> 6) The security setup should probably be mentioned also (container
>>> vs. non-container authentication, etc)
>>> These minor things aside, I think we could have a really good web
>>> testing framework here!  It works, is fast, and is very visual (i.e.
>>> it's easy to debug the errors, since you see them immediately).
>>> /Janne, happy and about to keel over from exhaustion

View raw message