12 Replies Latest reply on Sep 26, 2012 2:22 AM by bonigv

    Support for cross-test deployment

    jfrenetic

      Will there be support for cross-test deployment?

       

      For example, what if I have TestFoo.java and TestBar.java and I want them to operate on the same deployment.

       

      Also, what if I want to run tests against an application already deployed on the server?

       

      I know it's hardly possible, since tests should be bundled in the same application archive, but maybe something could be done here...

       

      Also, I'm having doubts if micro-deployment strategy is a correct approach for Integration Testing at all

        • 1. Re: Support for cross-test deployment
          jfrenetic

          Could someone from Arquillian Dev team possibly share his thoughts on this?

           

          I think this might be very useful, because sometimes I don't want to redeploy my application for each test in a test suite.

          • 2. Re: Support for cross-test deployment
            kito99

            Unless I'm mistaken, the official response is "tough luck" or "use another app server". So even though I love the concept of Arqullian, I've written it off for slow containers like WAS.

             

            I still think it's a pretty serious limitation, though -- you should be able to a single deployment for an entire test suite, for example, without JRebel.

            • 3. Re: Support for cross-test deployment
              alrubinger

              What we've slated for the next API of Arquillian (can't be done now, as it'd break backwards-compatibility, unless we do some new API extension...) is to decouple the test event lifecycle from the event handlers.  This would then let us wire up deployment actions alongside appropriate events to give you the type of flexibility you're requesting here.  Aslak might be able to update you on the roadmap for that.

               

              And the "microdeployment" strategy is great for integration testing!  You don't have to integrate EVERYTHING all at once.   In fact, microdeployments really help testing integration as you piece things together, and prevents the "big bang" integration test.

              1 of 1 people found this helpful
              • 4. Re: Support for cross-test deployment
                alrubinger

                I'll raise this again with the team at our meeting at JavaOne.  Perhaps there's something we *can* do without breaking back-compatibility. Thanks, guys for the input.

                • 5. Re: Support for cross-test deployment
                  alrubinger

                  And what you SHOULD be doing is writing off the slow containers!  Or using a remote Arquillian adaptor so that you don't start/stop between test runs, and only worry about deployment time between tests.

                  • 6. Re: Support for cross-test deployment
                    jfrenetic

                    Thanks a lot for such a quick response!

                    Hopefully, something could be done about this in the future

                     

                    And the "microdeployment" strategy is great for integration testing!  You don't have to integrate EVERYTHING all at once.

                    You see, our application consists of multiple ejb modules, all packaged in ear. I'm not sure if this could be called integration testing when those modules are tested separately. But that's a different problem, sorry for off-topic

                    • 7. Re: Support for cross-test deployment
                      alrubinger

                      Anton Shaykin wrote:

                      You see, our application consists of multiple ejb modules, all packaged in ear. I'm not sure if this could be called integration testing when those modules are tested separately. But that's a different problem, sorry for off-topic

                      Might be off-topic for here, but this is a central theme in our message: any time you combine two or more components, you're integrating.  Including just a single EJB and an application server.

                      1 of 1 people found this helpful
                      • 8. Re: Support for cross-test deployment
                        kito99

                        Developers don't always have control over the container choice, and some of them, like WAS (before Liberty Profile) take a looong time just to deploy an app, even if you don't restart the server.

                        • 9. Re: Support for cross-test deployment
                          alrubinger

                          I know.   Was just being cheeky.

                          • 10. Re: Support for cross-test deployment
                            aslak

                            It's definitely planned as a feature, but can't be done without SPI changes. It's one of the two top features for 2.0 (along propper isolation with embedded containers)

                            • 11. Re: Support for cross-test deployment
                              kito99

                              Thanks for the update, Aslak. That's good to know.

                              • 12. Re: Support for cross-test deployment
                                bonigv

                                Thanks @aslak.  Deploy once test all is a fature I want yesterday.  Across my two ejb maven modules across my project, I have 1200+ test cases.  My build time has bumped up by 30 minutes just because of switching from ejb3unit to arquillian.  I am going to have tough time explaining to everyone that this 'IS' a good thing .  Using glassfish embedded 3 now.  Of course I get to use the Ejb 3.1 featuresets and hibernate 4 with arquillian.  But something that increases my unit testing time is not going to go down well with engineering for long.  As long as there is a definite direction towards understanding the need for this feature we are good. 

                                 

                                Personally I will also try to see whether it is something hackable.  At least specific for glassfish3.  What I am thinking is, if some way I can have an annotation support that tells not to undeploy it should work.  Something that checks whether to redeploy.