6 Replies Latest reply on Jul 1, 2010 1:39 PM by Aslak Knutsen

    testing GateIn with Arquillain

    Matt Wringe Master

      Trying out Arquillian as part of some GateIn testing. GateIn (www.jboss.org/gatein) is a portal server, which is a web application running on top of JBossAS and it also integrates itself into the application server (for things like detecting when new web archives are deployed, etc). Its more complex than a normal webapplication would usually be.

       

      A typical test sequence would be something like
      1) configure and start the server (usually this is created from scratch each time as we don't want a previous test run to contaminate the server setup).
      2) deploy a test portal setup (ie what we want to test). May be more than one archive.

      3) run tests. This may include deploying/undeploying test portlets (war). We may want to deploy and undeploy multiple wars during a test.
      5) stop server

       

      Arquillian seems really cool in the way the tests are run on the server (which allows for use to gain easy access to our portal services to test). But it seems a bit limiting right now for us: create single archive, deploy archive and tests to server, run tests.

       

      Right now I can use cargo to create a new server setup, configure the server, and deploy my test portal archives. Then use Arquillian to deploy a single test portlet archive and run tests (in this case I wouldn't be running the tests on this archive directly but on the portal services, which would access the archive). This would work ok for some of our simple tests.

       

      [actually, I can't even use Arquillian to deploy a test portlet since it doesn't currently allow for in_container war deployables for AS 5. I need cargo to deploy this too and then use a dummy jar deployable since Arquillian has a requirement that something has to be deployed.]

       

      A few suggestions that would make Arquillian easier for us:

       

      - have the deployed test archive deploy separately from the archive which contains the tests (kindof like as_client but the archive which contains the tests is also be deployed on the server. This would also get around the war deployables not being able to be deployed in_container). I might like to be able to test the archive itself, not the combined archive and tests.

       

      - deployment lifecycle support. Being able to deploy and undeploy multiple archives independently of each other during the tests.

       

      - better server setup support. I have seen a few jiras about adding additional files and archives to the server, but it would be nice to have something like create a new clean server each time for test. Since I can use cargo to do this right now its not a big problem.

       

      - being able to inject a microcontainer bean into the test

       

      - being able to keep the test archives around after the test. If I am creating a test and its failing, I might want to check and see if there is something strange with the archive. I wouldn't want to do this all the time, but a flag to enable this option would be nice. Currently I put a delay in my test and then copy it to another folder before it gets deleted.

       

      Any thoughts on feedback on this? Sorry if I missed a feature that already exists or is planned, or if I am suggesting something beyond the scope of what Arquillian wants to prove.

       

      I guess I should look into how extensible Arquillain is and how difficult it would be to add these features to our tests.

        • 1. Re: testing GateIn with Arquillain
          Pete Muir Master

          Matt Wringe wrote:

          - have the deployed test archive deploy separately from the archive which contains the tests (kindof like as_client but the archive which contains the tests is also be deployed on the server. This would also get around the war deployables not being able to be deployed in_container). I might like to be able to test the archive itself, not the combined archive and tests.

          Interesting idea, should be easy to support. I think file a feature request.

           

          - deployment lifecycle support. Being able to deploy and undeploy multiple archives independently of each other during the tests.

           

          - better server setup support. I have seen a few jiras about adding additional files and archives to the server, but it would be nice to have something like create a new clean server each time for test. Since I can use cargo to do this right now its not a big problem.

          Both are really the same thing IMO - anyway on the roadmap - https://jira.jboss.org/browse/ARQ-67

           

          - being able to inject a microcontainer bean into the test

          A good thing to contribute IMO :-)

           

          - being able to keep the test archives around after the test. If I am creating a test and its failing, I might want to check and see if there is something strange with the archive. I wouldn't want to do this all the time, but a flag to enable this option would be nice. Currently I put a delay in my test and then copy it to another folder before it gets deleted.

          Agreed. I filed a JBIDE JIRA to allow you to do this easily from the IDE, but it would be good to support this directly. File a feature request.

          • 2. Re: testing GateIn with Arquillain
            Matt Wringe Master

            Pete Muir wrote:

            - deployment lifecycle support. Being able to deploy and undeploy multiple archives independently of each other during the tests.

             

            - better server setup support. I have seen a few jiras about adding additional files and archives to the server, but it would be nice to have something like create a new clean server each time for test. Since I can use cargo to do this right now its not a big problem.

            Both are really the same thing IMO - anyway on the roadmap - https://jira.jboss.org/browse/ARQ-67

             

             

            There are actually a few things mentioned here, ARQ-67 doesn't handle any of them.

             

            - being able to run the tests on a clean server. Each time I run a test I want to be able to start with an untouched server instance. I don't want previous test runs to affect future tests. I don't want to have people updating their server instances themselves since those changes could be changed later and cause test reproducibilty problems across different machines.

            - being able to configure the server. I may need to make changes to the servers configuration files, so being able to overwrite a configuration file before the server starts is needed.

            Not sure if this is within the scope of what Arquillain wants to do (for now I will have to use cargo to setup the server and start it).

             

            - I want to be able to control the lifecycle of the deployments. I want to be able to deploy and undeploy archives independently, and at anypoint during the test (not just deploy all archives at the start of the test). I may need to test the behaviour of how two or more archives interact and what happens when they get deployed in a different order, if they can handle an archive being removed and then redeployed, etc..

             

            ARQ-67 only handles deploying more than one resource at a time.

             

            Ideally I would really like to see from Arquillian:

            - remove the requirement on having an @deployment archive. This isn't even a real requirement as I can tell it to just deploy an empty jar.

            - separate the archive(s) which are under test and the archive which contains the tests.

            - allow the tests to define how and when it wants to deploy archives.

             

            I don't really care too much for how the server is setup and configured, cargo handles this nicely.

             

            Right now what I am doing is using an empty jar for the @deployment requirement, and then having my itself test handle deploying the archives I want to test (which means I need to pass to the test where the server is running and where the archives I need to test are located, and then having the test moving those files across).

            • 3. Re: testing GateIn with Arquillain
              Pete Muir Master

              Matt Wringe wrote:

               

              Pete Muir wrote:

              - deployment lifecycle support. Being able to deploy and undeploy multiple archives independently of each other during the tests.

               

              - better server setup support. I have seen a few jiras about adding additional files and archives to the server, but it would be nice to have something like create a new clean server each time for test. Since I can use cargo to do this right now its not a big problem.

              Both are really the same thing IMO - anyway on the roadmap - https://jira.jboss.org/browse/ARQ-67

               

               

              There are actually a few things mentioned here, ARQ-67 doesn't handle any of them.

               

              - being able to run the tests on a clean server. Each time I run a test I want to be able to start with an untouched server instance. I don't want previous test runs to affect future tests. I don't want to have people updating their server instances themselves since those changes could be changed later and cause test reproducibilty problems across different machines.

              Agreed. But I strongly believe this is better handled by the build tool than by Arquillian itself (it's a simple delete, download, unzip operation). But we should definitely work out how to best to do this (perhaps in the Maven JBoss plugin?). ALR, WDYT?

               

              - being able to configure the server. I may need to make changes to the servers configuration files, so being able to overwrite a configuration file before the server starts is needed.

              Not sure if this is within the scope of what Arquillain wants to do (for now I will have to use cargo to setup the server and start it).

              Definitely in the scope of Arquillian. I would suggest filing a separate feature request for this. It will likely be backed by ARQ-67 support as that will allow us to copy artifacts (e.g. an xml file) to any location on the server.

               

              - I want to be able to control the lifecycle of the deployments. I want to be able to deploy and undeploy archives independently, and at anypoint during the test (not just deploy all archives at the start of the test). I may need to test the behaviour of how two or more archives interact and what happens when they get deployed in a different order, if they can handle an archive being removed and then redeployed, etc..

              Again, I would suggest a JIRA, these could be great additions for a 1.1 or 1.2 release I think.

               

              - remove the requirement on having an @deployment archive. This isn't even a real requirement as I can tell it to just deploy an empty jar.

              Agreed, file a JIRA.

               

              - separate the archive(s) which are under test and the archive which contains the tests.

              - allow the tests to define how and when it wants to deploy archives.

              Both covered above (ARQ-67 and the RFE you will file)

              • 4. Re: testing GateIn with Arquillain
                Andrew Rubinger Master

                Pete Muir wrote:

                 

                Matt Wringe wrote:

                 

                Pete Muir wrote:

                - deployment lifecycle support. Being able to deploy and undeploy multiple archives independently of each other during the tests.

                 

                - better server setup support. I have seen a few jiras about adding additional files and archives to the server, but it would be nice to have something like create a new clean server each time for test. Since I can use cargo to do this right now its not a big problem.

                Both are really the same thing IMO - anyway on the roadmap - https://jira.jboss.org/browse/ARQ-67

                 

                 

                There are actually a few things mentioned here, ARQ-67 doesn't handle any of them.

                 

                - being able to run the tests on a clean server. Each time I run a test I want to be able to start with an untouched server instance. I don't want previous test runs to affect future tests. I don't want to have people updating their server instances themselves since those changes could be changed later and cause test reproducibilty problems across different machines.

                Agreed. But I strongly believe this is better handled by the build tool than by Arquillian itself (it's a simple delete, download, unzip operation). But we should definitely work out how to best to do this (perhaps in the Maven JBoss plugin?). ALR, WDYT?

                 

                 

                ATM we advise the copying of JBossAS instances as configured via the Maven dependency plugin, tied to the pre-integration-test phase:

                 

                JBoss Embedded AS | Quickstart and Runnable Example

                 

                Of course this will only make one installation.  You could make N manually, and each test would use a new JBOSS_HOME, but that's really really ugly and doesn't scale.

                 

                I don't think, however, that new server instances is the responsibility of Arquillian.  And generally speaking I don't much like tests to depend upon Maven plugin execution because everything should be runnable from the IDE.

                 

                Perhaps the solution here is to create some extension to Arquillian which can be applied declaratively: it would clean up logs, remove the data dir, etc.  So not re-unpacking AS as a new installation, but clearing the stuff affected by running the server?  BTW this is how we make the real AS distribution: the integration testsuite runs against an installed instance, and when done, we ZIP up everything with proper exclusions.

                 

                S,

                ALR

                • 5. Re: testing GateIn with Arquillain
                  Michael Schuetz Novice

                  Has Arquillian GateIn support already been scheduled?

                   

                  Thanks and regards

                  Michael

                  • 6. Re: testing GateIn with Arquillain
                    Aslak Knutsen Master

                    There is work planned to have GateIn support yes.