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 Sun, 10 Dec 2006 09:10:49 GMT

On Dec 8, 2006, at 1:29 PM, Prasad Kashyap wrote:

> David,
>
> Check out this patch http://people.apache.org/~prasad/manifestcp.patch
>
> Apply it from the geronimo/testsuite/depoyment-testsuite directory.
>
> It will create 2 directories under it.
> -- The manifestcp will create the ear for.
> -- The test-manifestcp will deploy and undeploy it.
>
> Throw your testcases under test-manifestcp.

When I apply the patch I get files with many copies of the content.   
Assuming this builds for you can you commit it?

IIRC there there aren't any tests needed for this, if it deploys it  
works.  When it's committed I'll check.

I think I'd prefer everything including the tests to be under the  
manifestcp dir, but we can try to rearrange this later.  I think we  
need to study how to best set this up.

thanks
david jencks

>
> Cheers
> Prasad
>
> On 12/8/06, David Jencks <david_jencks@yahoo.com> wrote:
>>
>> 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