geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Convention on dropping tests under the test framework
Date Fri, 08 Dec 2006 17:34:02 GMT

On Dec 8, 2006, at 6:30 AM, Prasad Kashyap wrote:

> On 12/8/06, David Jencks <david_jencks@yahoo.com> wrote:
>
>> For instance it might be useful to have a maven archetype to set up
>> everything except the app to test and the actual test cases.
>>
>> thanks
>> david jencks
>>
>
> I have alrady written an archetype plugin called
> testsuite-archetype-plugin that will let you create a testsuite with
> an empty testset project under it. Please see
> http://cwiki.apache.org/GMOxDEV/integration- 
> testing.html#IntegrationTesting-Gettingstarted
>
> However, in your case, since you don't want us to be createing any moe
> testsuites till we have colected enough tests, this is what you should
> do :
>
> 1) just make a copy of test-deployment, (say call it cxf-deployment)
> 2) use it's child profile to go thro the complete maven lifecycle -
> compile, build and test your apps.
> 3) it's parent (deployment-testsuite) will take care of the server
> start/stop and reporting for you.

I wasn't able to make anything work where the app being tested was  
under the directory that's a copy of *-deployment.  Now I'm working  
with a structure where the *-deployment is a child of the app build  
directory, and it seems to work.  Once I straighten out the tests so  
they work I'll check it in and we can see if it can be reorganized to  
be simpler.

I was wondering why the SeleniumTestSupport and ExtendedSelenium  
classes were in the tests themselves rather than in a support jar.   
I'd think these would be used by just about all tests.

FIxing the tests is likely to take me all day.  If you'd like to  
demonstrate what you think is correct structure you could set  
something up with the test ear from GERONIMO-2125

http://issues.apache.org/jira/secure/attachment/12336683/manifestcp- 
itest-v3.jar

which has a maven project to build a test ear.  With luck deploying  
it stlll works :-)

thanks
david jencks

>
> Cheers
> Prasad
>
> Cheers
> Prasad
>
>
>
>
>> On Dec 7, 2006, at 8:31 PM, Prasad Kashyap wrote:
>>
>> > Since there were some questions today on where to drop new  
>> tests, I'll
>> > take a stab at creating a convention. Feel free to offer your
>> > suggestions so that we can modify it as we go along.
>> >
>> > We  began by having 2 testsuites just as an example.
>> > geronimo/testsuite/
>> >     console-testsuite
>> >     deployment-testsuite
>> >
>> > But almost everything can fall under the category of the
>> > deployment-testsuite since most tests do need some deployable
>> > artifact. So I think we should use the deployment-testsuite  
>> purely for
>> > testing the deploy tool. Especially, it should be used to test
>> > features like hot-deploy, redeploy and undeploy which have had  
>> JIRAs
>> > before.
>> >
>> > We should categorize the tests so that they reflect the broad
>> > functional areas of the server.
>> >
>> > * web-testsuite (servlets, jsp, jstl)
>> > * enterprise-testsuite (ejb, jpa, jms, jacc, jta, javamail, jaf   
>> etc)
>> > * mgmt-testsuite (jee management, deployment)
>> > * webservices-testsuite (wsee, jaxb, stax, saaj, ws-metadata etc)
>> > * performance-testsuite (server startup time, server footprint etc)
>> > * security-testsuite
>> > * console-testsuite
>> > * regression (compatibility)
>> >
>> > If nobody has any objection to this top categorization, I shall go
>> > ahead and create these testsuites over the weekend. Meanwhile  
>> you may
>> > drop your tests in the existing testsuites for now. I shall move  
>> them
>> > appropriately.
>> >
>> > Lastly, how do we deal with super apps like daytrader that can span
>> > across multiple testsuites ?
>> >
>> > Cheers
>> > Prasad
>>
>>


Mime
View raw message