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. Cheers Prasad On 12/8/06, David Jencks <[EMAIL PROTECTED]> wrote:
On Dec 8, 2006, at 6:30 AM, Prasad Kashyap wrote: > On 12/8/06, David Jencks <[EMAIL PROTECTED]> 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 >> >>
