>From: "CONNER, BRENDAN (SBCSI)" <[EMAIL PROTECTED]> > > 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. >
You might look at junitee (www.junitee.org). It allows you two run junit test cases under the web container where you would have the JNDI stuff. > - 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) 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)" > >>>> > >>>> 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] >
