Would it make sense to create a list of tests for each version, and have the verifier/test plugin only run the ones on that test? It would be sort of like the old integration-tests.txt file, except the particular file might be selected using the Maven version being used? This way, the tests remain unchanged from version to version (which I think we'd all agree is key), and we're only maintaining one set of tests.
Dunno...I haven't put too much thought into that, it just seems like it might be a simple solution. WDYT? On 10/30/06, Jason van Zyl <[EMAIL PROTECTED]> wrote:
On 30 Oct 06, at 3:12 AM 30 Oct 06, Brett Porter wrote: > I was thinking that as well, wrt testng. It would be really good to > establish some dependencies so that tests that are bound to fail > could just be skipped if an earlier one fails. Also, the groups > would be useful to run artifact related tests together, etc. > > I'm not sure about branching the tests - I thought that was what we > were trying to get away from by taking them away from the > corresponding tags/branches/trunk? > This is what Kenney and I chatted about. Dan doesn't agree with us ... yet :-) Thanks, Jason. > On 30/10/2006, at 7:01 PM, Dan Fabulich wrote: > >> I should also mention that TestNG has some handy facilities to handle >> marking tests as "skipped" based on fancy criteria... I still think >> branching the tests is the cleanest way to handle this, but running >> integration tests in TestNG is a good fit regardless. >> >> -Dan >> >>> -----Original Message----- >>> From: Dan Fabulich >>> Sent: Sunday, October 29, 2006 11:33 PM >>> To: Maven Developers List >>> Subject: RE: integration tests: how to handle versions? >>> >>> Jason and I had discussed this briefly a while ago... In my >>> opinion, >>> the best/clearest way to handle this is to branch the integration >> tests. >>> >>> -Dan >>> >>>> -----Original Message----- >>>> From: Brett Porter [mailto:[EMAIL PROTECTED] >>>> Sent: Sunday, October 29, 2006 4:24 PM >>>> To: Maven Developers List >>>> Subject: integration tests: how to handle versions? >>>> >>>> Hi, >>>> >>>> I like the new integration testing method. However, I've just added >> a >>>> test that will only work with a version of Maven that fixes the bug >>>> (which I have sorted out locally, just doing some other checks >> before >>>> committing). >>>> >>>> So the two things we need to do: >>>> - exclude that test from Maven < 2.0.5 >>>> - display what Maven version is being used before starting, because >> I >>>> keep accidentally using the wrong version. >>>> >>>> Maybe the <prerequisite /> tag in the pom.xml for the test (and >>>> handle the error case from Maven), or just have a condition in the >>>> test that if mavenVersion < 2.0.5(which would need to be >>>> obtained in >>>> the verifier, perhaps by scraping mvn -version), output SKIPPED. >>>> >>>> Any thoughts on the best way to do this? >>>> >>>> - Brett >>> >>> >> _____________________________________________________________________ >> __ >>> Notice: This email message, together with any attachments, may >> contain >>> information of BEA Systems, Inc., its subsidiaries and >> affiliated >>> entities, that may be confidential, proprietary, copyrighted >> and/or >>> legally privileged, and is intended solely for the use of the >> individual >>> or entity named in this message. If you are not the intended >> recipient, >>> and have received this message in error, please immediately return >> this >>> by email and then delete it. >>> >>> -------------------------------------------------------------------- >>> - >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >> >> _____________________________________________________________________ >> __ >> Notice: This email message, together with any attachments, may >> contain >> information of BEA Systems, Inc., its subsidiaries and >> affiliated >> entities, that may be confidential, proprietary, copyrighted >> and/or >> legally privileged, and is intended solely for the use of the >> individual >> or entity named in this message. If you are not the intended >> recipient, >> and have received this message in error, please immediately return >> this >> by email and then delete it. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
