Thanks for the info. I'm definitely interested in simplifying my testing strategy to the extent that it's possible, so any suggestions are welcome. In particular I'm trying to avoid having different versions of my delegates (one version that returns a dummy result and another that actually makes the call to the Session Bean doing the work), but I'm open to other ways of doing things.
So how are people unit testing their JSF Action methods in a 3-tier application using the Shale Test Framework? Are they actually keeping around two different versions of their delegates to avoid having to do the JNDI lookups? I'm open to altering my approach to fit the tool, provided I know what the recommended approach is. - Brendan -----Original Message----- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Laurie Harper Sent: Thursday, February 16, 2006 10:47 AM To: user@struts.apache.org Subject: Re: [SHALE] Using the Test Framework Brendan, I think the upshot of all this is that you *may* be able to use the Shale test framework to mock out the JSF side of things, but run the resulting tests using Cactus so you still get the container functionality you need. However, it's not something anyone's done so it may or may not work in practice. That said, I think you'd be over-complicating your testing strategy to the point of diminishing returns. You'd effectively be building a hybrid integration testing / unit testing solution. You'd probably be much better served by taking a functional testing approach using something like, as Craig suggested, HtmlUnit or Cannoo. I'd also recommend taking a look at Selenium [1]; I haven't used it yet, but it looks very promising, depending on your needs. L. [1] http://www.openqa.org/selenium/ CONNER, BRENDAN (SBCSI) wrote: > So are you agreeing that there is currently no framework that can > currently do round-trip testing as I've described it? Or am I missing > something? > > Just trying to get a practical answer. ;-) > > - Brendan > > P.S. We *are* using delegates, DAO factories, etc. It just would be > nice to be able to test our code from the Action method once those > delegates have been filled in and are no longer stubs. > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Sent: Thursday, February 16, 2006 8:57 AM > To: user@struts.apache.org > Subject: RE: [SHALE] Using the Test Framework > > > What Cactus does is allow your test code to run from within the > container, controlled by the same test code outside the container. It > connects the two with a proxy arrangement. It can call anything in your > code or available to your code. > > Cactus *is* a PITA to work with, and complicated to think about, IMHO. > I've gotten away from using it in recent years by abstracting interfaces > that might need to do things like JNDI lookups and providing mock > versions for out-of-container testing. In my experience, it things are > hard to test, it generally indicates design issues. Usually the > dependency chains are long and concrete. Constructs like a Business > Delegate or Abstract DAO Factory help break up the dependencies. > > Recommended reading: > > "The Dependency Inversion Principle" by Robert C. Martin > (http://www.objectmentor.com/resources/articles/dip.pdf) > > "Patterns of Enterprise Application Architecture" by Martin Fowler > (http://www.amazon.com/exec/obidos/ASIN/0321127420/alberg30-20) > > - George Dinwiddie > http://idiacomputing.com/moin/FavoriteBooks > > > >> -----Original Message----- >> From: CONNER, BRENDAN (SBCSI) [mailto:[EMAIL PROTECTED] >> Sent: Wednesday, February 15, 2006 5:55 PM >> To: Struts Users Mailing List >> Subject: RE: [SHALE] Using the Test Framework >> >> >> I think Cactus works OK with JNDI lookups, etc., since it's >> just a Servlet. However, I think it falls apart when trying >> to reference stuff like FacesContext.getInstance(), since >> we're not in the middle of an actual JSF life cycle event. >> >> So my quandary seems to be that, for round trip testing >> starting at an Action method: >> >> 1. I can't use the Shale Test Framework, because it would >> fail when doing EJB calls. 2. I can't use Cactus, because it >> would fail when trying to do FacesContext.getInstance(). 3. >> Because of the above, there is no standard testing framework >> to use for this type of testing. >> >> Is that a fair assessment? I'm not complaining; I'm just >> trying to verify my understanding. >> >> - Brendan >> >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >> Behalf Of Craig McClanahan >> Sent: Wednesday, February 15, 2006 4:49 PM >> To: Struts Users Mailing List >> Subject: Re: [SHALE] Using the Test Framework >> >> >> On 2/15/06, CONNER, BRENDAN (SBCSI) <[EMAIL PROTECTED]> wrote: >>> But let's say my test executes an action method on my application's >>> managed bean. That method uses the mock objects and then tries to >> call >>> a Session Bean to do a lookup, but it appears that the lookup fails >>> because the action method is not really running in a Web Container, >>> correct? Is this all happening in stand-alone application >> mode? How >>> can I set up my test to run in a Web Container so that it has access >> to >>> JNDI lookups, etc.? Do I have to use Cactus for that? >> >> It should be possible to use Cactus for that kind of testing, >> but I've never looked how Cactus deals with JNDI lookups or >> session beans. >> >> - Brendan >> >> >> Craig >> >> -----Original Message----- >>> From: Gary VanMatre [mailto:[EMAIL PROTECTED] >>> Sent: Tuesday, February 14, 2006 2:22 PM >>> To: Struts Users Mailing List >>> Subject: RE: [SHALE] Using the Test Framework >>> >>> >>>> From: "CONNER, BRENDAN (SBCSI)" <[EMAIL PROTECTED]> >>>> >>>> OK, sorry for being a little dense about this, but, if, >> for example, >>> my >>>> application code is referencing a FacesContext object, and my Test >>> code >>>> initializes MockFacesContext, what is the mechanism that makes my >>>> application use the values that are in MockFacesContext? I >> understand >>>> that MockFacesContext is a subclass of FacesContext, but I don't >>>> understand how my application ends up using the values in the >>>> MockFacesContext instance instead that were initialized >> by the test >>>> case. >>>> >>> The idea is that you extend a base test case that sets up the mock >>> objects. They are scoped so that they can be referenced from test >>> methods in a subclass. >>> >>> Take a look at the AbstractJsfTestCase >>> >> (http://svn.apache.org/viewcvs.cgi/struts/shale/trunk/test-fra > mework/src >> /java/org/apache/shale/test/base/AbstractJsfTestCase.java?view=markup) >> >> >> >> >>> - Brendan >>> >> 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] --------------------------------------------------------------------- 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]
