On 30 Oct 06, at 2:24 PM 30 Oct 06, Brett Porter wrote:
This is really a question for the users list, but since we're here
these are probably the alternatives you have:
- use profiles to distringuish which tests run when (by
reconfiguring the surefire plugin)
- using testng with groups to categorise the tests
All good except for system properties Might be running in the
embedder for more then one version at a time.
- using a system property to enable/disable tests from within their
code
But TestNG looks perfect for this sort of thing. Not sure if you can
dynamically groups so that we could have strategies like looking in
the POM for info and using the standard annotations but I'm sure it
will require some flexibility as it gets more sophisticated.
Jason.
- Brett
On 30/10/2006, at 7:44 PM, [EMAIL PROTECTED] wrote:
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]
---------------------------------------------------------------------
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]
