Arquillian
  1. Arquillian
  2. ARQ-74

Base test deployment on project in which test is run

    Details

    • Similar Issues:
      Show 10 results 

      Description

      A common testing scenario will be to deploy the artifact generated by the current project, and run tests against it.

      For example, say my project was building a war, I want to be able to deploy that war, inserting the test case and any beans into the deployment, and have my tests run.

      In this case the deep control of the classpath through shrinkwrap is getting in the way.

        Issue Links

          Activity

          Hide
          Dan Allen
          added a comment -

          The general agreement is that this is likely going to be related to Maven, or some abstraction of the project, so adding a link to an issue discussing similar approaches.

          Show
          Dan Allen
          added a comment - The general agreement is that this is likely going to be related to Maven, or some abstraction of the project, so adding a link to an issue discussing similar approaches.
          Hide
          Dan Allen
          added a comment -

          This topic recently came up in the Testing SIG in the thread "Testing deployment of pre-built .war to various web servers" - https://community.jboss.org/message/730868#730868

          The current state of affairs / workaround, as Marek pointed out, is

          ShrinkWrap.create(ZipImporter.class, "foo.war").importFrom(new File("target/foo.war"))
          

          The caveat is that you have to make sure your test runs in the integration-test maven phase, that is after "package".

          That workaround, however, is at odds with the goal of the Arquillian project, which is to skip the build when testing.

          In that thread, I proposed an annotation that would build a deployment (using ShrinkWrap Resolvers) based on the current project's artifact. Here's how it would be used:

          @RunWith(Arquillian.class)
          @DeployProjectArtifact
          public class MyFunctionalTest {
              @ArquillianResource
              private URL url;
           
              @Test
              public void shouldBehaveSomeWay() {
                 // make a request to the url
              }
          }
          

          Of course, in this case, a @Deployment method would not be required (which is possible through an extension).

          I had hacked up an extension prototype a while back that implements this idea, though it uses the older ShrinkWrap Resolver...which would be replaced by the new ShrinkWrap Resolver APIs, which are being discussed in this forum thread: https://community.jboss.org/message/731735

          https://gist.github.com/2477705

          According to Karel:

          Now we have a ShrinkWrap Resolver Maven Plugin, @DeployProjectArtifact might work without specifying path to the pom, active profiles, etc. However, IDE support for the plugin is still an open question here.

          This is an actual show-stopper for the moment https://issues.jboss.org/browse/SHRINKRES-18. If implemented, creating an Arquillian extension with @DeployProjectArtifact annotation would be an easy task.

          Karel also suggested that this annotation should be a part of ShrinkWrap Maven Resolver. Once on classpath, you can do Maven magic for deployments.

          Alternate names for the annotation are as follows:

          • @DeployBuildOutput
          • @DeployProjectArchive

          I prefer either "project artifact" or "project archive" since it's not just the output, but rather the package that the build is creating.

          Show
          Dan Allen
          added a comment - This topic recently came up in the Testing SIG in the thread "Testing deployment of pre-built .war to various web servers" - https://community.jboss.org/message/730868#730868 The current state of affairs / workaround, as Marek pointed out, is ShrinkWrap.create(ZipImporter.class, "foo.war" ).importFrom( new File( "target/foo.war" )) The caveat is that you have to make sure your test runs in the integration-test maven phase, that is after "package". That workaround, however, is at odds with the goal of the Arquillian project, which is to skip the build when testing. In that thread, I proposed an annotation that would build a deployment (using ShrinkWrap Resolvers) based on the current project's artifact. Here's how it would be used: @RunWith(Arquillian.class) @DeployProjectArtifact public class MyFunctionalTest { @ArquillianResource private URL url; @Test public void shouldBehaveSomeWay() { // make a request to the url } } Of course, in this case, a @Deployment method would not be required (which is possible through an extension). I had hacked up an extension prototype a while back that implements this idea, though it uses the older ShrinkWrap Resolver...which would be replaced by the new ShrinkWrap Resolver APIs, which are being discussed in this forum thread: https://community.jboss.org/message/731735 https://gist.github.com/2477705 According to Karel: Now we have a ShrinkWrap Resolver Maven Plugin, @DeployProjectArtifact might work without specifying path to the pom, active profiles, etc. However, IDE support for the plugin is still an open question here. This is an actual show-stopper for the moment https://issues.jboss.org/browse/SHRINKRES-18 . If implemented, creating an Arquillian extension with @DeployProjectArtifact annotation would be an easy task. Karel also suggested that this annotation should be a part of ShrinkWrap Maven Resolver. Once on classpath, you can do Maven magic for deployments. Alternate names for the annotation are as follows: @DeployBuildOutput @DeployProjectArchive I prefer either "project artifact" or "project archive" since it's not just the output, but rather the package that the build is creating.
          Hide
          Peter Probst
          added a comment -

          I would even go a step further. Each single deploy comes with a runtime cost. So there is a need to deploy the project artifact once and then run all testclasses against the project artifact. This would speed up the tests in our case enormously.

          Show
          Peter Probst
          added a comment - I would even go a step further. Each single deploy comes with a runtime cost. So there is a need to deploy the project artifact once and then run all testclasses against the project artifact. This would speed up the tests in our case enormously.

            People

            • Assignee:
              Unassigned
              Reporter:
              Pete Muir
            • Votes:
              8 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

              • Created:
                Updated: