CONNER, BRENDAN replied: > 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?
No, but I'm saying that you'll likely find it messy and difficult to mock out part of a big environment but include other parts. > Just trying to get a practical answer. ;-) I agree with Laurie that it's more practical to unit test in isolation, and then system test the entire system. If you cover all the boundary conditions with your unit tests, then the system testing is a lot more tractable. > - 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. Stubs, fakes and mocks are subtly different things. For unit testing, I think you'll still want to inject a fake or a mock that behaves (and in the case of a mock, verifies the usage) the same as the real thing. Not only does this free you from difficult test setups, but it allows you to create conditions that may be impossible to create using the real thing. - George > -----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]
