4 Replies Latest reply on Mar 8, 2011 1:04 PM by Keith Babo

    SwitchYardTestCase @Before

    Keith Babo Master

      SwitchYardTestCase currently performs all of it's setup in @Before and tear down in @After.  This is seamless and works great, but presents an issue if a subclass of SwitchYardTestCase has it's own setup to perform *before* the setup in SwitchYardTestCase @Before happens.  I ran into this when trying to specify a HTTP URL for the WSDL location of a SOAP binding in my switchyard config.  I need to create the WS endpoint before the deployer kicks the component activator to resolve the WSDL.

       

      My current workaround is to perform the initialization of the WS endpoint in the constructor for my test.  Perhaps this is what we recommend to folks if they require this behavior.  Would love to hear if there's a better solution.    It appears as though jUnit will execute @Before in the super->sub order of inheritance, which makes sense.

        • 1. Re: SwitchYardTestCase @Before
          Tom Fennelly Master

          Yeah... interesting little conundrum.  I think this is a symptom of doing things by extension vs composition, just like we were saying on email.  I think it would be better to mix in CDI, SOAP etc into tests by composition vs extension.  You can probably manage the ordering a bit more easily that way.

           

          One approach I was thinking of (and it would be really easy to code it and try it) would be to allow test aspects such as CDI and SOAP to be mixed in by specifying them using something like a @TestMixIn annotation on the base SwitchYardTestCase impl e.g.

           

          @TestMixIn(SOAPGatewayMixIn.class, CDIBeansMixIn.class)
          public class MyAppTest extends SwitchYardTestCase {
          
              @Test
              public void blahTest() {
                  ….
              }
          }
          

           

          And the TestMixIn classes are simple pojo's that use the JUnit @Before and @After annotations (and maybe some others?) to do the setup and teardown for that aspect of the test ala....

           

          public class SOAPGatewayMixIn {
          
              @Before
              public void doSomethingBefore() {
                  // ….
              }
          
              @After
              public void doSomethingAfter() {
                  // ….
              }
          
              // etc...
          }
          
          public class CDIBeansMixIn {
          
              @Before
              public void doSomethingBefore() {
                  // ….
              }
          
              @After
              public void doSomethingAfter() {
                  // ….
              }
          
              // etc...
          }
          

           

          SwitchYardTestCase would create the mix-ins and execute their @Before and @After methods, in the order they're defined in the annotation (obviously @After would be in reverse order).  Similarities with multiple inheritance.

           

          I think this might get around the issue we discussed yesterday (inheritance Vs composition) and also get around the issue you refer to here because you can set up the order in which the mix-ins are mixed in.

           

          Just an idea.

          • 2. SwitchYardTestCase @Before
            Keith Babo Master

            This looks interesting.  So a "MixIn" can potentially define two things:

             

            1) @Before and @After methods are enlisted in the jUnit test lifecycle by SwitchYardTestCase.  The @Before of MixIns are invoked in defintion order before SwitchYardTest case setup is performed.  The @After of MixIns are invoked in reverse definition order after SwitchYard test case tear down is performed.

             

            2) Utility methods specific to a given MixIn type are defined as statics on the MixIn class.

             

            Does that sound right?  Only alternative I can think of is that MixIns could be defined as member variables of the test class and annotated with @MixIn.  This would provide a test-local scope to any state stored in a particular MixIn, which you would not get with a static method.  To be honest, I'm not sure how important this will be, but I'm throwing it out there for discussion.  The disadvantage with this alternative approach is that defining the order of MixIn initialization becomes messier.

            • 3. Re: SwitchYardTestCase @Before
              Tom Fennelly Master

              Exactly.

               

              I think you could provide runtime access to a particular MixIn by providing a getMixIn utility method on SwitchYardTestCase that could be used by the test code ala

               

              CDIBeanMixIn beanMixIn = getMixIn(CDIBeanMixIn.class);
              CdiX cdiX = beanMixIn.getSomethingCDISpecific();
              

               

              I think defining them as a type level annotation (vs as a member var) might be a bit clearer/cleaner.

              • 4. SwitchYardTestCase @Before
                Keith Babo Master

                Okie dokie.  We can always start with type-level annotation and if a requirement for field-level annotation pops up we can deal with in then.

                 

                https://issues.jboss.org/browse/SWITCHYARD-168