>From: "CONNER, BRENDAN (SBCSI)" <[EMAIL PROTECTED]> > > 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. >
If you are using the shale test framework with simple junit tests, the test framework doesn't digest your faces-confg.xml anyway. You have to do that kind of setup in the test cases. The isolated code you want to test in the managed beans would just use a indirect reference (the managed bean name of the delegate). But, I hear what you are saying about making the deployable unit not build dependent. It is ideal when you can take the same ear that was tested in a QA environment and push that same ear to production without rebuilding or repackaging. We are able to do this in WAS with JNDI environment namespace bindings. The application config parameters are managed at the cell, node or server versus a application artifact. > 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. > Sounds like a decoupling all the same - just a lower level. Gary > - 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)" > > > > 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] >
