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. - 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 <[EMAIL PROTECTED]> wrote: > > > >From: "CONNER, BRENDAN (SBCSI)" <[EMAIL PROTECTED]> > > > > 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]
