One approach could be to have a main() overload taking an additional
Environment argument to abstract access to environment variables, system
properties, and standard I/O; and returning an int as the possible
System.exit() value.
That way, you can easily stub the environment for tests.
Your
It depends on the criticality of your command line tools. One
interessting approach is the one by the SpringBoot guys. They run
commands in a Docker container and collect stdout to check the behaviour
of their System V start script.
=>
Have you considered writing an integration test that invoked your command
line tool from the command line?
When you use tools like Failsafe, JUnit, etc, you can know that the process
works in that environment, but the real world execution won't be the same.
While most of your corner cases,
The thing is, not even the classes in the WAR show up in the test module.
Are WAR-type modules never supossed to be added as dependencies? I read
Try packaging a utility class file in a War, and then run it from
java -cp blah.war YourClass. War files are not understood by the
JVM, only Jar
Thanks Wayne, really useful explanations. I already had googled a bit
about this but, as always, one cannot expect to find good examples or
practices out there and I have a high respect for this list opinions,
specially about the maven way which I see now again and again ends up
always with
For our project, I decided to use a profile and naming convention to include
the integration tests. I'm not extremely satisfied with the solution, but
it allows us to get cobertura coverage reports from our integrations tests,
which was of enough value to us to accept the extra inconvenience.
On Wed, Apr 8, 2009 at 10:22 AM, Jason Voegele ja...@jvoegele.com wrote:
I'm interested in knowing the current thinking on best practices for
integration testing in Maven projects. I did find a few articles on the Web
that discuss this issue, but they all are a bit old now. The most relevant
On Thu, Feb 5, 2009 at 3:07 PM, David C. Hicks dhi...@i-hicks.org wrote:
Essentially, I have two modules - the war module and the
integration-test module. (I intend to split the war stuff up soon, as
well.) Obviously, the integration-test module must have a dependency on
war (it can't run
Thanks, Wendy! I must have been blind to miss that option in my xml editor.
That was the trick.
Wendy Smoak wrote:
On Thu, Feb 5, 2009 at 3:07 PM, David C. Hicks dhi...@i-hicks.org wrote:
Essentially, I have two modules - the war module and the
integration-test module. (I intend to split
It seems to be something related to the 2.4.2 version of the surefire plugin.
If i use the 2.0.9 release but force the surefire plugin to use the 2.3
version of the surefire plugin then the test resources are copied correctly.
plugin
groupIdorg.apache.maven.plugins/groupId
Ok, this looks like I cleared this up myself, but the NEW question is,
what happens when there is ANOTHER module that depends on the assembly
of another.
So one of our app server artifact has integration tests, but it needs
one of these registry type servers up and running.
How can I say, during
Good day to you, Arnaud,
Just a hunch
The Symptom:
Somewhere along the stacktrace, a component failed to get composed because
of a NoClassDefFoundError exception.
Solution:
I think the expected transitive dependency was broken. You may want to
declare the binary containing the
franz see [EMAIL PROTECTED] writes:
Good day to you, Arnaud,
Good day to you too Franz,
Solution:
I think the expected transitive dependency was broken. You may want to
declare the binary containing the NoClassDefFoundError class as a direct
dependency of your project. ..also, you may
On 9/12/06, Donnchadh Ó Donnabháin [EMAIL PROTECTED] wrote:
I've added the following to buildplugins:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-plugin/artifactId
executions
execution
phaseintegration-test/phase
That's perfect
Thanks
Donnchadh
On 9/12/06, Wendy Smoak [EMAIL PROTECTED] wrote:
On 9/12/06, Donnchadh Ó Donnabháin [EMAIL PROTECTED] wrote:
I've added the following to buildplugins:
plugin
groupIdorg.apache.maven.plugins/groupId
-Original Message-
From: Heck, Joe [mailto:[EMAIL PROTECTED]
Sent: mercredi 30 août 2006 22:54
To: Maven Users List
Subject: RE: Integration Testing
We have several different mechanisms running - but most of them are
honestly manual. The automated solution that one of our teams
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
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
-Original Message-
From: Ruel Loehr [mailto:[EMAIL PROTECTED]
Sent: jeudi 31 août 2006 16:10
To: Maven Users List
Subject: RE: Integration Testing
I appreciate the feedback. I think these are all valid workarounds, but
have my concerns about scalability and ease of use
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
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
Joe Heck wrote
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
There is a phase integration-test.
I think you could bind different existing plugin (compile, cargo, surefire)
using the execution, phase and goal tags.
I hope this info will guide you toward the solution you need.
Gilles
-Original Message-
From: Pablo [mailto:[EMAIL PROTECTED]
At 01:12 PM 9/8/2005, Craig McDaniel wrote:
One approach I've seen is to create *-acceptance projects to contain
the integration tests. For example, da-hibernate-acceptance. I would
end up with no tests in da-hibernate, and only tests in
da-hibernate-acceptance. Is this common? With this setup,
24 matches
Mail list logo
