I appreciate the feedback. I think these are all valid workarounds, but have my concerns about scalability and ease of use for users.
BTW, I'm not ranting here, just trying to show that use cases exist for which the functionality of M2 might need to improved upon. Our actual testsuite for JBossAS starts and stops different server configurations 15-20 times as well as starting up clusters of servers. From what I can see, to do this the maven way, I would need 15-20 integration projects which would be executed by hand or cruise control or 1 integration project with 15-20 profiles executed in the same fashion as above. Neither one of those solutions provides the same level of functionality as what I can achieve using ant. Another key point I have to deal with is simply the migration and the user experience. Currently they can go into our testsuite and issue: ant tests At which time our entire testsuite will run, performing integration testing for all configurations. I can't take away that functionality. SO....to achive this, it sounds like I need to write a plugin which allows many executions, where For each execution a) configure server and start it b) deploy app c) run unit tests d) undeploy app e) stop server Ruel Loehr JBoss, a division of Red Hat QA ----------------------------- 512-342-7840 ext 2011 Yahoo: ruelloehr Skype: ruelloehr AOL: dokoruel -----Original Message----- From: Christophe DENEUX [mailto:[EMAIL PROTECTED] Sent: Thursday, August 31, 2006 8:28 AM To: Maven Users List Subject: Re: Integration Testing Hi, We have also the same mechanism that the one described by Joe. Moreover, the functional tests are associated to a specific profile to be executed only if asked. We use jWebUnit to write our webapp tests cases. To use this mechanism with 3 different QA environments, you can use the Maven2 profile feature: in the M2_HOME/conf/settings.xml, define 3 profiles that are trigged by a variable as -Denv=env1 (or env2, env3). To automate all this, you can declare 3 builds (one for each QA environment) in your continuous integration server (for example, Continuum). ____________________________________________________________________________ Christophe DENEUX / Capgemini Sud / Méditerranée Technical Leader Tel: + 33 4 93 72 43 74 / www.capgemini.com Fax: + 33 4 93 21 02 95 Porte de l'Arénas - Entrée B / 455 Promenade des Anglais / 06200 Nice Join the Collaborative Business Experience ____________________________________________________________________________ Heck, Joe a écrit : > We have several different mechanisms running - but most of them are > honestly manual. The automated solution that one of our teams have come > up and and stuck with is the following: > > 1) set up a multi-module maven2 project, with one of those modules being > a functional test suite, another the WAR that we're pushing and banging > on. > 2) using cargo, we deploy the WAR produced to an instance of Tomcat > running on an available and preset QA machine. > 3) We invoke the functional tests (primarily httpunit stuff) locally. > > The "how to" for the separate functional test module setup was on this > earlier - the big pieces to note being that the functional test module > is set with POM packaging, and then plugins manually bound to the > various steps (in this case, the maven-surefire-plugin bound to the > integration-test phase and the cargo plugin bound to the > "pre-integration-test" phase) > > We've additionally set it up so that functional tests are only included > with a specific profile (originally named "functional-tests") so that > your personal builds will invoke them only when desired. > > Anything much more complex than this, and I think we'd need to reach out > of maven with a custom AntTask bound in there to do setup/teardown kinds > of work. > > -joe > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Ruel Loehr > Sent: Wednesday, August 30, 2006 1:33 PM > To: Maven Users List > Subject: Integration Testing > > I'd like to query the community and see how you guys are handling > integration testing in real world environments. > > I've looked through the list and the Better builds book, but didn't like > what I saw...... > > Here is the use case: > > Use Case A: > > A user has a project which builds a war. For integration testing the > war needs to be deployed in an app server. > The process will be to startup the app server, deploy the war, run unit > tests, stop the app server. > > Here is the gotcha. > > App servers can have many configurations. In this case, we would like > to test the functionality of this war on three different app server > configurations. Use case A would need to be executed 3 times > automatically, each time with a different server configuration. > > Assuming I already know how to modify the appserver configs, any > suggestions on how the repeated execution of this use could be achived > in scalable fashion (e.g. if I have 25 server configurations my build > file won't be a nightmare to maintain). > > In ant, it's pretty simple as I can just string together targets until > my heart is content. With maven, I feel I am imprisoned by the > lifecycle in this case. > > > > Ruel Loehr > JBoss, a division of Red Hat > QA > > > > This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.11.7/434 - Release Date: 8/30/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.11.7/434 - Release Date: 8/30/2006 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
