How do you handle the case of tests which don't have to or should be run every time?
In my case, I have tests which check external connectivity which means that other systems have to be up and running (and correctly configured) or the test will fail. Currently, I'm using exclude rules and run the connect tests manually but I'd prefer some kind of switch on the command line to enable them. For example, in the integration test, I'd like the tests to run always because there, the other systems should be up. In the development environment, they're only up when I ask for them. Regards, -- Aaron Digulla Brett Porter <[EMAIL PROTECTED]> schrieb am 30.10.2006 09:12:53: > 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? > > 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]
