Selenium

[David Jencks <da...@yahoo.com>]

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

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

Re: Selenium

[Jason Dillon <ja...@planet57.com>]

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...

--jason


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
>>
>

Re: Selenium

[Gianny Damour <gi...@optusnet.com.au>]

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
>