You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Alex Karasulu <ak...@apache.org> on 2014/03/13 03:54:57 UTC

[Failsafe] How to properly conduct integration tests on executable jar files

Hello,

I've got a module that builds an executable jar file using the Maven
Assembly Plugin. I'm trying to setup an integration test (in the same
module) that runs this executable jar file as a separate process and
interacts with it. To fire up the executable jar file, my integration test
requires the path to the executable jar file.

I'm trying to achieve this by passing a property to the integration-test
via system properties. This makes me feel really really dirty though and it
has issues: although the test runs on the CLI it does not in any IDE
without requiring further configuration (i.e. the property has to be
manually added to a run configuration).

After googling around a bit and reading the documentation there seems to be
no other option for this scenario. In case I'm overlooking something, I
wanted to ask here if there is a better way to start up this executable jar
file or pass in the needed parameters to do so in the integration test?

-- 
Best Regards,
-- Alex

Re: [Failsafe] How to properly conduct integration tests on executable jar files

Posted by Mirko Friedenhagen <mf...@gmail.com>.
Well with Netbeans you just add the following:

            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-surefire-plugin</artifactId>
                <version>${surefire.version}</version>
                <configuration>
                    <systemPropertyVariables>

<shadedJarPath>${project.build.directory}/${project.artifactId}-${project.version}-shaded.jar</shadedJarPath>
                    </systemPropertyVariables>
                </configuration>
            </plugin>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-failsafe-plugin</artifactId>
                <version>${surefire.version}</version>
                <executions>
                    <execution>
                        <id>default-integration-test</id>
                        <goals>
                            <goal>integration-test</goal>
                        </goals>
                    </execution>
                </executions>
                <configuration>
                    <systemPropertyVariables>

<shadedJarPath>${project.build.directory}/${project.artifactId}-${project.version}-shaded.jar</shadedJarPath>
                    </systemPropertyVariables>
                </configuration>
            </plugin>

and using the Java-task from Ant:

import org.apache.tools.ant.BuildException;
import org.apache.tools.ant.ExitStatusException;
import org.apache.tools.ant.Project;
import org.apache.tools.ant.taskdefs.Java;
import org.apache.tools.ant.types.Commandline;

public class ShadedIT {
    @Test
   public void testShaded() throws Exception {
        Java java = new Java();
        java.setProject(new Project());
        java.setFailonerror(true);
        java.setFork(true);
        java.setJar(shadedJar);
        Commandline.Argument arg = java.createArg();
        arg.setFile(csvFile);
        java.execute();
    }
}

This will be executed by failsafe from the CLI and you may run the
class from Netbeans without any special settings.
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/


On Thu, Mar 13, 2014 at 10:50 AM, Adrien Rivard <ad...@gmail.com> wrote:
> If you are using Eclipse you could also pass the system property directly
> to the JRE. ( Windows/Preferences/installed JRE/ edit /default VM arguments)
> It require less work than putting it in all run configuration, but all your
> process will have it.
>
>
>
> On Thu, Mar 13, 2014 at 8:56 AM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
>> You could use test resource filtering to put the path into a resource file
>> on the test classpath.
>>
>> That way the IDE will pick up the same path.
>>
>> On Thursday, 13 March 2014, Alex Karasulu <ak...@apache.org> wrote:
>>
>> > Hello,
>> >
>> > I've got a module that builds an executable jar file using the Maven
>> > Assembly Plugin. I'm trying to setup an integration test (in the same
>> > module) that runs this executable jar file as a separate process and
>> > interacts with it. To fire up the executable jar file, my integration
>> test
>> > requires the path to the executable jar file.
>> >
>> > I'm trying to achieve this by passing a property to the integration-test
>> > via system properties. This makes me feel really really dirty though and
>> it
>> > has issues: although the test runs on the CLI it does not in any IDE
>> > without requiring further configuration (i.e. the property has to be
>> > manually added to a run configuration).
>> >
>> > After googling around a bit and reading the documentation there seems to
>> be
>> > no other option for this scenario. In case I'm overlooking something, I
>> > wanted to ask here if there is a better way to start up this executable
>> jar
>> > file or pass in the needed parameters to do so in the integration test?
>> >
>> > --
>> > Best Regards,
>> > -- Alex
>> >
>>
>>
>> --
>> Sent from my phone
>>
>
>
>
> --
> Adrien Rivard

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: [Failsafe] How to properly conduct integration tests on executable jar files

Posted by Adrien Rivard <ad...@gmail.com>.
If you are using Eclipse you could also pass the system property directly
to the JRE. ( Windows/Preferences/installed JRE/ edit /default VM arguments)
It require less work than putting it in all run configuration, but all your
process will have it.



On Thu, Mar 13, 2014 at 8:56 AM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:

> You could use test resource filtering to put the path into a resource file
> on the test classpath.
>
> That way the IDE will pick up the same path.
>
> On Thursday, 13 March 2014, Alex Karasulu <ak...@apache.org> wrote:
>
> > Hello,
> >
> > I've got a module that builds an executable jar file using the Maven
> > Assembly Plugin. I'm trying to setup an integration test (in the same
> > module) that runs this executable jar file as a separate process and
> > interacts with it. To fire up the executable jar file, my integration
> test
> > requires the path to the executable jar file.
> >
> > I'm trying to achieve this by passing a property to the integration-test
> > via system properties. This makes me feel really really dirty though and
> it
> > has issues: although the test runs on the CLI it does not in any IDE
> > without requiring further configuration (i.e. the property has to be
> > manually added to a run configuration).
> >
> > After googling around a bit and reading the documentation there seems to
> be
> > no other option for this scenario. In case I'm overlooking something, I
> > wanted to ask here if there is a better way to start up this executable
> jar
> > file or pass in the needed parameters to do so in the integration test?
> >
> > --
> > Best Regards,
> > -- Alex
> >
>
>
> --
> Sent from my phone
>



-- 
Adrien Rivard

Re: [Failsafe] How to properly conduct integration tests on executable jar files

Posted by Stephen Connolly <st...@gmail.com>.
You could use test resource filtering to put the path into a resource file
on the test classpath.

That way the IDE will pick up the same path.

On Thursday, 13 March 2014, Alex Karasulu <ak...@apache.org> wrote:

> Hello,
>
> I've got a module that builds an executable jar file using the Maven
> Assembly Plugin. I'm trying to setup an integration test (in the same
> module) that runs this executable jar file as a separate process and
> interacts with it. To fire up the executable jar file, my integration test
> requires the path to the executable jar file.
>
> I'm trying to achieve this by passing a property to the integration-test
> via system properties. This makes me feel really really dirty though and it
> has issues: although the test runs on the CLI it does not in any IDE
> without requiring further configuration (i.e. the property has to be
> manually added to a run configuration).
>
> After googling around a bit and reading the documentation there seems to be
> no other option for this scenario. In case I'm overlooking something, I
> wanted to ask here if there is a better way to start up this executable jar
> file or pass in the needed parameters to do so in the integration test?
>
> --
> Best Regards,
> -- Alex
>


-- 
Sent from my phone

Re: [Failsafe] How to properly conduct integration tests on executable jar files

Posted by Alex Karasulu <ak...@apache.org>.
On Thu, Mar 13, 2014 at 4:54 AM, Alex Karasulu <ak...@apache.org> wrote:

> Hello,
>
> I've got a module that builds an executable jar file using the Maven
> Assembly Plugin. I'm trying to setup an integration test (in the same
> module) that runs this executable jar file as a separate process and
> interacts with it. To fire up the executable jar file, my integration test
> requires the path to the executable jar file.
>
> I'm trying to achieve this by passing a property to the integration-test
> via system properties. This makes me feel really really dirty though and it
> has issues: although the test runs on the CLI it does not in any IDE
> without requiring further configuration (i.e. the property has to be
> manually added to a run configuration).
>
> After googling around a bit and reading the documentation there seems to
> be no other option for this scenario. In case I'm overlooking something, I
> wanted to ask here if there is a better way to start up this executable jar
> file or pass in the needed parameters to do so in the integration test?
>
>
Thanks for the feedback. I eventually used Stephen's suggestion (test
resource filtering) and it works like a champ for both the IDE and the CLI.

-- 
Best Regards,
-- Alex