Mailing-List: contact continuum-dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: continuum-dev@maven.apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <DA6FB76E-BDF2-416C-A656-BA342B7D810A@apache.org>
References: <10581062-1593-415D-BD02-5E6747C4FCA6@apache.org>
 <E7A63260-B68B-424F-ABE8-97FE01E49955@apache.org>
 <DA6FB76E-BDF2-416C-A656-BA342B7D810A@apache.org>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <455F3663-6FD9-4F47-9F38-80FDFAF757B7@apache.org>
Content-Transfer-Encoding: 7bit
From: Brett Porter <brett@apache.org>
Subject: Re: selenium tests
Date: Thu, 28 Dec 2006 11:27:55 +1100
To: continuum-dev@maven.apache.org

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