4 Replies Latest reply on Oct 14, 2011 11:35 AM by Aslak Knutsen

    Can't @Deployment methods be optional?

    Mousavi Jahan Abadi S. M. Newbie

      I know that static @Deployment methods are necessary for Arquillian to find following information:

      - Archive file type declaration (JAR? WAR?..)

      - Archive file name

      - Archive file contents (classes, property files, ...)

      - Deployment setting definition (multi-server support, ...)

      - Deployment order definition

      . and so on


      And, currently, for test case classes, it is REQUIRED to have such static @Deployment methods.

      But, I want to ask to re-think whether isn't it possible to make these methods optional???


      Please consider the typical test situation.

      Basically, with regards to test, there are 2 categories of code:

      - Code to be tested (target web appliction to be tested).

      - Test code.

      Since, the Arquillian is "In-Container Test Tool", in typical situation, we can consider that "code to be tested" is already deployed/running inside the web container. So, in typical situation, Arquillian don't need to archive the "code to be tested" and Arquillian only need to archive/deploy/undeploy "Test Code". In normal test cases, each test case is single self-containing test class, it don't have any relation with other test classes. The result of this matter is that for many situations only one JAR file (with any default name) that contains the test class itself is enough.


      In my Java projects, I have many test cases using Arquillian. However, the result is that in all of them I am copying following un-useful code again and again:



      public static JavaArchive createTestArchive(){

           return ShrinkWrap.create(JavaArchive.class,"test.jar");



      So, my suggestion is that Arquillian be smarter, and make such kind of static @Deployment methods optional, and have a defualt behavior, whenever the @Deployment method doesn't exist (instead of making it error).


      Please don't tell me that defining one super class and adding the above method to super class can solve it. For sure, I know that solution, and users of Arquillian can use this approach. But, for Arquillian as a test framework, that want to have minimum code addition (related to Arquillian), I think it is not good design pattern.

        • 1. Re: Can't @Deployment methods be optional?
          Aslak Knutsen Master

          From > 1.0.0.CR2 or so, Arquillian does not require a @Deployment method defined on the TestClass, but this will force as client mode and assume your testing a existing deployment as a client(no incontainer).


          But, you can add incontainer behavior yourself by writing a Extension and creating a Archive as you want outside of your testclass.


          Implement a LoadableExtension, register it in META-INF/services/org.jboss.arquillian.core.spi.LoadableExtrension


          The create a impl of the org.jboss.arquillian.container.test.spi.client.deployment.DeploymentScenarioGenerator and register it in the the LoadableExtension.


          Something in the lines of:


              *  register in META-INF/services/org.jboss.arquillian.core.spi.LoadableExtension 
              *  containing the fully qualified name for AutoInContainerTestExtension 
             public class AutoInContainerTestExtension implements LoadableExtension
                public void register(ExtensionBuilder builder)
                   builder.service(DeploymentScenarioGenerator.class, AutoRegisterDeployment.class);
             public class AutoRegisterDeployment implements DeploymentScenarioGenerator
                public List<DeploymentDescription> generate(TestClass testClass)
                   return Arrays.asList(
                         new DeploymentDescription("AUTO-GEN",
          1 of 1 people found this helpful
          • 2. Re: Can't @Deployment methods be optional?
            Mousavi Jahan Abadi S. M. Newbie

            Aslak, thanks for your reploy, and now I understand that @Deployment become optional in 1.0.0.RC2, and we can add in-container behavior, using the SPI extensions.


            But, I would like to make one suggestion (as a user of framework):

            - As you have mentioned, make the  @Deployment methods being optional.

            - If @Deployment method doesn't exist, default behavior be IN-CONTAINER deployment/test of current test case class (exactly same as implementation of above "AutoRegisterDeployment" class, you have mentioned in your reply).

            - If @Deployment method doesn't exist, ONLY for methods with "@RunAsClient" annotation, make it to be a test in client mode.


            The reason for above suggestion is that I think as the title logo of this page (Arquillian) says: "Test In-Container", the incontainer test should be default behavior. And, also as a user that want to use Arquillian for unit test, it is too much/difficult to add SPI extension to support in-container behavior.


            Just a suggestion to make Arquillian more user-friendly.

            • 3. Re: Can't @Deployment methods be optional?
              Fekete Kamosh Newbie


              I am afraid I still do not follow the solution described here.

              Could you please give me a clue, how to perform incontainer tests of already deployed EJBs?


              Suppose this situation:

              1) SLSB GreetingManagerBean (example from https://github.com/arquillian/arquillian/tree/master/examples/domain/src/main/java/com/acme/ejb) is deployed onto JBoss 6.

              2) Server is started and running


              I would like to make use of incontainer injection and perform test like this:



                   private GreetingManager greetingManager;



                   public void shouldBeAbleToInjectEJB() throws Exception {

                        String userName = "Earthlings";

                        Assert.assertEquals("Hello " + userName, greetingManager.greet(userName));



              How to do it without applying new deploy of GreetingManagerBean?


              Thank you,


              • 4. Re: Can't @Deployment methods be optional?
                Aslak Knutsen Master

                You can't if GreeterManager is a Local bean. Local beans can normally only be accessed within their own module, and you can't change a already deployed module.


                If GreeterManager is a Remote bean on the other hand, you can call is as a client from the client side or deploy a 'dummy' deployment to move the test case to the container side and invoke it from there. But it won't be in the same module as GreeterBean