continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Thakur" <rahul.thakur.x...@gmail.com>
Subject Re: selenium tests
Date Fri, 29 Dec 2006 07:22:52 GMT
The container shouldn't be downloaded everytime by default.

But I agree perhaps another temp location is a better candidate for 
setting up container installation - may be 'target' directory under top 
level root?

Rahul

----- Original Message ----- 
From: "Brett Porter" <brett@apache.org>
To: <continuum-dev@maven.apache.org>
Sent: Friday, December 29, 2006 6:56 PM
Subject: Re: selenium tests


> 8) store the cargo container installs somewhere other than target, so 
> I can run clean tests without the massive download.
>
> On 28/12/2006, at 12:51 PM, Franz Allan Valencia See wrote:
>
>> On 12/27/06, Brett Porter <brett@apache.org> wrote:
>>> 6) we should use dbunit or something similar to set the database up
>>> into a consistent state for the respective tests, and tear it down
>>> again. Running through the web interface in tearDown is time
>>> consuming, and error prone (if you add a new test that doesn't tear
>>> itself down, then a different test fails).
>>>
>>> On 27/12/2006, at 3:57 PM, Brett Porter wrote:
>>>
>>> > see below
>>> >
>>> > On 27/12/2006, at 3:09 PM, Brett Porter wrote:
>>> >
>>> >>
>>> >> On 27/12/2006, at 2:08 PM, Brett Porter wrote:
>>> >>
>>> >>> Hi,
>>> >>>
>>> >>> A few observations on these. Does anyone else have outstanding
>>> >>> "todos" in this area? Would like to gatehr them up and get them
>>> >>> resolved to make them useful.
>>> >>>
>>> >>> 1) these need to be run regularly to be really useful. They
>>> >>> aren't part of the main build ( a good idea, since it requires a
>>> >>> UI and takes forever). Is there a way to run them in rhino so we
>>> >>> can run them as part of the main build and then turn on the 
>>> >>> other
>>> >>> profiles when we have mutliple platforms to test on?
>>> >>>
>>> >>> 2) they currently all fail - Franz says it's due to UI changes 
>>> >>> we
>>> >>> haven't caught up to. See #1 :) Are the UI changes abstracted
>>> >>> sufficiently that this will be a quick fix, or is it going to a
>>> >>> be a big search and replace job? They fail due to "user
>>> >>> authenticated" assertions failing.
>>> >>
>>> >> Fixed the fundamental problem, now it's just UI changes.
>>> >>
>>> >> Down to 14 :)
>>> >
>>> > Down to 5 (AccountSecurityTest, ProjectGroupTest). I'll look 
>>> > later.
>>> >
>>> >>
>>> >>>
>>> >>> 3) Is there a way to get it to stop after a certain number of
>>> >>> failures? 39 open firefox browser instances caused my mac to
>>> >>> kernel panic.
>>> >>>
>>> >>> 4) I underestand that the plexus-security related tests are
>>> >>> shared across both webapps. Should we put some helper code into
>>> >>> plexus-security that can be used by these tests so that changes
>>> >>> there can be addressed there (preferably using the example
>>> webapp)?
>>> >>>
>>> >>> I think this is the list of things to get done - I can put them
>>> >>> in JIRA if there isn't anything extra or anything I've missed in
>>> >>> the list.
>>> >>>
>>> >>> - brett
>>> >
>>> > 5) the continuum tearDown should not swallow exceptions (retthrow
>>> > them, but that means changing the abstract selenium test case to
>>> > throw it too)
>>> >
>>>
>>
>> 7.) Switch to Tomcat 5.5.17 to support the email validations ( a bug
>> in 5.5.20 prohibits that ). 


Mime
View raw message