continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <br...@apache.org>
Subject Re: selenium tests
Date Fri, 29 Dec 2006 08:17:02 GMT
Only on clean - which you want to do to clean out the database, etc  
but not the container install.

I would rather the cargo plugin used the maven repository, myself :)

- Brett

On 29/12/2006, at 6:22 PM, Rahul Thakur wrote:

> 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