>From: "CONNER, BRENDAN (SBCSI)" <[EMAIL PROTECTED]> > > 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 > - Brendan > > -----Original Message----- > From: Hermod Opstvedt [mailto:[EMAIL PROTECTED] > Sent: Thursday, February 16, 2006 3:22 PM > To: 'Struts Users Mailing List' > Subject: SV: Re: [SHALE] Using the Test Framework > > > Hi > > Easy: Spring. It's all done with configuration. In a no "EJB container > available" setting, you configure spring to return a different service than > when you have EJB container available. > > > Hermod > > -----Opprinnelig melding----- > Fra: CONNER, BRENDAN (SBCSI) [mailto:[EMAIL PROTECTED] > Sendt: 16. februar 2006 22:08 > Til: Struts Users Mailing List > Emne: RE: Re: [SHALE] Using the Test Framework > > Sounds good. So how do you isolate your Web Layer from the EJB layer during > testing and then re-establish the linkage during deployment in your > environment? > > - Brendan > > -----Original Message----- > From: Hermod Opstvedt [mailto:[EMAIL PROTECTED] > Sent: Thursday, February 16, 2006 2:59 PM > To: 'Struts Users Mailing List' > Subject: SV: Re: [SHALE] Using the Test Framework > > > Hi > > I totally agree with Craig. There is a huge difference between Unit testing > and Integration testing. We do both, using different tooling for the > different test types. > > Hermod > > > -----Opprinnelig melding----- > Fra: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] På vegne av Craig > McClanahan > Sendt: 16. februar 2006 20:18 > Til: Struts Users Mailing List > Emne: Re: Re: [SHALE] Using the Test Framework > > On 2/16/06, Gary VanMatre wrote: > > > > > > >From: "CONNER, BRENDAN (SBCSI)" > > > > > > OK, I'll look at that. But, out of curiosity, how is the Shale Test > > > Framework being used by people now? Is it being used mostly for > > > non-3-tier applications? What is the extent of the problem space in > > > which it is useful? (Obviously, it's not meant for stand-alone Java > > > J2SE applications, because then there would be no need for JSF support.) > > > > > > > > > I would say that there is a percentage of folks that build applications > > that don't use EJB but still use good design patterns and are able to > > load-balance across several web containers without the complexity of > > EJB. For that cult, the Shale test framework would snap right in. > > > Another way to look at this is to think about what is the scope of a "unit > test". Conceptually, I would think of two *different* unit tests being > needed in this environment: > > * A unit test for the backing bean (Shale view controller or whatever). To > test this bean, > you would need to mock out the session bean itself. (And, the test > framework > should provide JNDI lookup mocking, which the Shale test frameworkd > doesn't > have yet). > > * A unit test for the session bean itself. For this, you'd want a framework > that mocks the EJB environment, and would have nothing to do with JSF > or web tier APIs. > > It's possible that you also want a more end-to-end test -- but to me that's > a "system integration" test, rather than unit tests. > > Craig > > > --------------------------------------------------------------------- > 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] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
