-
1. Re: SwitchYardTestCase @Before
tfennelly Mar 8, 2011 3:13 AM (in response to kcbabo)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
kcbabo Mar 8, 2011 10:29 AM (in response to tfennelly)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
tfennelly Mar 8, 2011 12:21 PM (in response to kcbabo)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
kcbabo Mar 8, 2011 1:04 PM (in response to tfennelly)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.