geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <>
Subject Re: Selenium
Date Sat, 01 Mar 2008 05:12:28 GMT
I usually start out using the IDE's record muck to get the basic  
clicks down, then generate Java code and then massage it to actually  
test something and drop it into a junit...


On Mar 1, 2008, at 7:30 AM, Gianny Damour wrote:

> On 29/02/2008, at 6:04 AM, David Jencks wrote:
>> I went to a selenium get together Monday and think we have some  
>> great opportunities for improving and speeding up our testsuite.
>> The bits I think would be of most benefit, from my perspective as a  
>> non-test-engineer, are:
>> selenium grid.  This lets you run basically any number of selenium  
>> tests in parallel against a single server.  For instance we can run  
>> all the console tests in parallel.
>> selenium IDE.  This lets you record your actions on a web site as a  
>> test.  You can also edit the results for e.g. better independence  
>> of the xpath expressions on the specific html
> Hi,
> IMHO, we should stay away from the recording feature provided by  
> Selenium IDE: it generates code which is really hard to maintain on  
> the long run. Or, generated code could be refactored to better  
> abstract user interactions. Ideally, Selenium tests are written  
> first and, based on many observations, this results in way better  
> integration tests.
> I also believe that the xpath element selection style is weak and I  
> think that location of elements by ids is a better way to go,  
> especially as we have full control of the source code.
> Thanks,
> Gianny
>> There's another tool that was discussed that lets you abstract the  
>> xpath expressions but I can't remember the name or find  
>> documentation about it.  If our pages' formatting don't jump around  
>> too much it might not be incredibly useful for us.
>> thanks
>> david jencks

View raw message