I understand the concept; I'm just worried about the amount of effort required to mock up all those calls, relative to the complexity of my Action methods themselves. One nice thing about using JSF is that our Action methods themselves are almost ridiculously simple (since the business logic is in the Session Beans and JSF takes care of data conversion to and from the managed beans); we no longer do anything explicitly with the Servlet classes (e.g., request or session), so we're basically just packaging up data into DTOs, calling Session Bean methods (via the delegates), catching exceptions, and optionally queueing messages. We just want to do quick checks at the Action level to make sure we're not doing something stupid.
Thanks for the info. I'll have to chew on this a little.... ;-) - Brendan -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig McClanahan Sent: Thursday, February 16, 2006 1:18 PM To: Struts Users Mailing List Subject: 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]
