6 Replies Latest reply on Nov 15, 2015 7:24 AM by Luis Fernandes

    Lifecycle questions

    Laird Nelson Apprentice

      Since a test runner in JUnit can effectively define its own lifecycle, and since JUnit rules can also do the same thing, I was wondering if there was a state diagram or something somewhere that could show the lifecycle imposed by the Arquillian test runner.


      I'm looking for the best place to add database setup and teardown code, and I'd like to do it without having to subclass anything.


      When the Arquillian test runner is in control, are @Before and @After annotations honored?  What about when I have several test methods?  Are such "setup"/"teardown" methods in a @Run(IN_CONTAINER) run from inside the container, or outside of it?


      It appears to me that @Before and @After won't behave the same way they will in JUnit normally, but I could be wrong about that.




        • 1. Re: Lifecycle questions
          Laird Nelson Apprentice

          Aaaaand of course within moments of posting, I discover this: http://community.jboss.org/thread/157577?tstart=0


          ...which seems to indicate that @Before and @After happen before the @Deployment is dealt with by the Arquillian test runner.  My refined question then is this: is this by design, or will it be modified?




          • 2. Re: Lifecycle questions
            Aslak Knutsen Master

            Deploy/Undeploy is actaully mapped to BeforeClass/AfterClass, before it reaches your BeforeClass and after it reached your AfterClass.


            In Alpha-4, there is a bug that cause the lifecycles to be executed both on the client and in container. In beta-1 they should only execute in-container.


            The lifecycle is a bit different in-contianer with Arquillian tho, since ALL lifecycles will be called incontainer pr @Test on the client side.


            So @BeforeClass/@AfterClass won't work incontainer, @Before/@After will. (conceptually the same as normal junit)

            • 3. Re: Lifecycle questions
              Laird Nelson Apprentice

              Thanks; that one line about the bug just saved me probably hours of work.  :-)  I'll make sure to put a guard in to prevent double execution.

              • 4. Re: Lifecycle questions
                Laird Nelson Apprentice

                So--and this is more academic than practical--if I wanted to clean up and then re-arrange some database tables outside of the container before each test, I'm kind of on my own?  This would seem to be the case if indeed @Before/@After run in-container.  In practice, like I said, I don't think it will make much difference.  Would be nice to have both.  :-)

                • 5. Re: Lifecycle questions
                  Aslak Knutsen Master

                  Yea, we haven't landed the discussion yet, but we need both. We also have some other client side lifecycles that could be interesting:


                  e.g. @BeforeDeployment / @AfterDeployment


                  maybe something alla:


                  @Before @Run(AS_CLIENT)  <-- run @Before on client side

                  @Before <-- run @Before in container


                  Or even with multi contianer/deployment support:


                  @Before @DeploymentTarget("X") <-- only execute @Before incontianer when @Test is targeting the X deployment

                  • 6. Re: Lifecycle questions
                    Luis Fernandes Newbie



                    In the last version, Before/After class, Before/After Method is not working inside the container.

                    Is there any workaround for this?