struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "CONNER, BRENDAN \(SBCSI\)" <bc1...@att.com>
Subject RE: Re: [SHALE] Using the Test Framework
Date Thu, 16 Feb 2006 22:38:46 GMT
Thanks, George.  Good points.

...except I find it easier to test method invocations than Http
responses.

- Brendan

-----Original Message-----
From: George.Dinwiddie@wellsfargo.com
[mailto:George.Dinwiddie@wellsfargo.com] 
Sent: Thursday, February 16, 2006 4:17 PM
To: user@struts.apache.org
Subject: RE: Re: [SHALE] Using the Test Framework


I'm just telling you what I find easier.

> -----Original Message-----
> From: CONNER, BRENDAN (SBCSI) [mailto:bc1378@att.com] 
> Sent: Thursday, February 16, 2006 4:51 PM
> To: Struts Users Mailing List
> Subject: RE: Re: [SHALE] Using the Test Framework
> 
> 
> Although those are interesting comments, they don't address 
> my basic point about the amount of effort required to mock up 
> all those calls.
> ;-)
> 
> - Brendan
> 
> -----Original Message-----
> From: George.Dinwiddie@wellsfargo.com 
> [mailto:George.Dinwiddie@wellsfargo.com] 
> Sent: Thursday, February 16, 2006 3:41 PM
> To: user@struts.apache.org
> Subject: RE: Re: [SHALE] Using the Test Framework
> 
> 
> CONNER, BRENDAN wrote:
> > 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.
> 
> Good!  I also recommend having the Session Bean methods call 
> like-named methods in a Business Logic class, doing similar 
> catching of exceptions. Then you can test your Business Logic 
> without the container.  The Session Bean is just a facade on 
> the Business Logic, the same as the Business Delegate is a 
> facade on the Session Bean.  In fact, if I'm not using EJBs, 
> I'm likely to use the Business Delegate facade directly on 
> the Business Logic.  Then, if the transactional support of 
> EJBs becomes desirable, I just insert an extra facade layer 
> in the code.
> 
> > We
> > just want to do quick checks at the Action level to make sure 
> > we're not doing something stupid.
> 
> Of course, but that can be done through the UI itself, rather 
> than inside the web container at the Action level.  It's more 
> work in some ways, but less in others.  And it gives you a 
> warm fuzzy about the whole application.
> 
>  - George
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Mime
View raw message