Sorry, ignore that last paragraph. ;-) - Brendan
-----Original Message----- From: CONNER, BRENDAN (SBCSI) Sent: Wednesday, February 22, 2006 3:47 PM To: Struts Users Mailing List Subject: RE: Re: [SHALE] Using the Test Framework Well, the thing that's nice about my approach is that all the configuration and testing changes take place completely outside of the application. Our application code (including the faces-config.xml and web.xml files) are under source control, and we don't want to modify any of that just to test the application code. We don't even want to do a separate test build with different configurations, because then we're testing something different than what will be in production. I was following the same pattern that the Shale Test Framework itself follows, namely, to create mock objects that, because they're declared under the same package and class names, end up being loaded by the classloader in place of the objects that usually get loaded. - Brendan -----Original Message----- From: Gary VanMatre [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 22, 2006 3:37 PM To: Struts Users Mailing List Subject: RE: Re: [SHALE] Using the Test Framework >From: "CONNER, BRENDAN (SBCSI)" <[EMAIL PROTECTED]> > > Are you saying I should register my delegates as JSF managed beans? > Sure, why not? The faces IoC container is not spring but you could still have some of the same benefits. In fact, you could snap in Spring down the road using the Shale Spring integration (http://struts.apache.org/struts-shale/features-spring-integration.html) . Gary > - Brendan > > -----Original Message----- > From: Gary VanMatre [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 22, 2006 2:49 PM > To: Struts Users Mailing List > Subject: RE: Re: [SHALE] Using the Test Framework > > > >From: "CONNER, BRENDAN (SBCSI)" > > > > In case anyone else was in the same boat I was in trying to run the > Shale Test > > Framework "in isolation" on the Web Tier of a 3-tier application, I > did come up > > with a technique that doesn't depend upon Spring. This is in the > context of > > using IBM's RSA IDE, but I imagine a similar technique would work in > other > > development environments. > > > > 1. I defined a simple Java project to contain the Shale Test framework > code (and > > JAR files) > > 2. I set up a dependency between that Java project and the Web > (application) > > project > > 3. I copied the delegate classes from the application to my new test > project, > > keeping the package names the same > > 4. I modified the new "mock" delegate classes to be stubs so they did > not try to > > invoke the EJB tier > > > > Then when I ran JUnit on the test project, it invoked the application > method, > > which proceeded to invoke the delegate, but the classloader loaded the > "mock" > > delegate class ahead of the application's delegate class, so the test > proceeded > > without invoking the EJB tier. > > > > If you registered your delegate's as managed beans, you wouldn't have to > make your mock delegates live in the same packages with the same names > (#3). Rather, you would have to register them with the Shale mock JSF > test framework in your test cases (design with more spring :-). > > Gary > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
