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 Wed, 22 Feb 2006 21:47:03 GMT
Well, the thing that's nice about my approach is that all the
configuration and testing changes take place completely outside of the
application.  Our application code (including the faces-config.xml and
web.xml files) are under source control, and we don't want to modify any
of that just to test the application code.  We don't even want to do a
separate test build with different configurations, because then we're
testing something different than what will be in production.

I was following the same pattern that the Shale Test Framework itself
follows, namely, to create mock objects that, because they're declared
under the same package and class names, end up being loaded by the
classloader in place of the objects that usually get loaded.

- Brendan

-----Original Message-----
From: Gary VanMatre [mailto:gvanmatre@comcast.net] 
Sent: Wednesday, February 22, 2006 3:37 PM
To: Struts Users Mailing List
Subject: RE: Re: [SHALE] Using the Test Framework


>From: "CONNER, BRENDAN (SBCSI)" <bc1378@att.com> 
>
> Are you saying I should register my delegates as JSF managed beans? 
> 

Sure, why not?  The faces IoC container is not spring but you could
still have some of the same benefits.  In fact, you could snap in Spring
down the road using the Shale Spring integration
(http://struts.apache.org/struts-shale/features-spring-integration.html)
.

Gary


> - Brendan 
> 
> -----Original Message----- 
> From: Gary VanMatre [mailto:gvanmatre@comcast.net] 
> Sent: Wednesday, February 22, 2006 2:49 PM 
> To: Struts Users Mailing List 
> Subject: RE: Re: [SHALE] Using the Test Framework 
> 
> 
> >From: "CONNER, BRENDAN (SBCSI)" 
> > 
> > In case anyone else was in the same boat I was in trying to run the 
> Shale Test 
> > Framework "in isolation" on the Web Tier of a 3-tier application, I 
> did come up 
> > with a technique that doesn't depend upon Spring. This is in the 
> context of 
> > using IBM's RSA IDE, but I imagine a similar technique would work in

> other 
> > development environments. 
> > 
> > 1. I defined a simple Java project to contain the Shale Test
framework 
> code (and 
> > JAR files) 
> > 2. I set up a dependency between that Java project and the Web 
> (application) 
> > project 
> > 3. I copied the delegate classes from the application to my new test

> project, 
> > keeping the package names the same 
> > 4. I modified the new "mock" delegate classes to be stubs so they
did 
> not try to 
> > invoke the EJB tier 
> > 
> > Then when I ran JUnit on the test project, it invoked the
application 
> method, 
> > which proceeded to invoke the delegate, but the classloader loaded
the 
> "mock" 
> > delegate class ahead of the application's delegate class, so the
test 
> proceeded 
> > without invoking the EJB tier. 
> > 
> 
> If you registered your delegate's as managed beans, you wouldn't have
to 
> make your mock delegates live in the same packages with the same names

> (#3). Rather, you would have to register them with the Shale mock JSF 
> test framework in your test cases (design with more spring :-). 
> 
> Gary 
> 
> --------------------------------------------------------------------- 
> 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