Re: Testing WO code

Yeah, what Jerry said!  :-)

My impression of the utility of Spring is that is allows you to glue  
unrelated things together.  Often OC/dependancy injection looks more  
to me like a hack around a problem rather than a good solution, but I  
_am_ biased.  The parts of WO are not unrelated, they are very  
gracefully designed to interoperate in a clean, layered manner.

For unit testing I've only ever used jUnit.  I've not even bothered  
with WOUnitTest.  That said, most of my tests have been run from  
inside Eclipse which has it's own jUnit GUI.

The only thing difficult to test with unit tests are WOComponents.   
My view is that you don't need unit tests for these.  The XP mantra  
is to test anything that might possibly break.  If you have code in  
your WOComponents that might possible break then you are writing them  
wrong.  Factor out the complex code into a POJO Controller class that  
can be tested the same as any class.  The WOComponent is the view,  
keep it really simple.  You still need to test their functionality  
via the HTTP interface but that is more functionality testing than  
unit testing.


Chuck


On Jul 18, 2005, at 9:34 AM, Jerry W. Walker wrote:

> Hi, Doug,
>
> On Jul 18, 2005, at 10:41 AM, Doug Hall wrote:
>
>> I'm still looking at WO/Wonder versus Spring/Hibernate/Tapestry.
>>
>> One of the benefits of using Spring is that you can separate  
>> dependent layers, and use IOC/dependancy injection (with  
>> configuration) to make them work together. This lets you better  
>> isolate the different layers of an application, which has the side  
>> effect of making testing much easier. (You can build your model  
>> classes entirely of POJOS and POJIs, for example.)
>>
>> So how does this play out in WO? How difficult is it to build an  
>> automated testing process for WebObjects (for example)? Am I  
>> missing some critical point in the development process? Is there a  
>> WO project available that helps one test their WO code?
>>
>
> I think you will get a dearth of answers because you're using  
> abbreviations that may not be too familiar to the members of this  
> mailing list. So, to get the ball rolling, let me take a shot.
>
> First, full disclosure:
>
>   *  I use WebObjects plain out of the box and develop in a Mac  
> environment.
>
>   * I haven't used Project Wonder (yet)
>
>   * I haven't developed any applications using JavaBeans and do my  
> best to avoid it.
>
> I think it can be fairly stated that nearly all WO projects are  
> built entirely of POJOs (Plain Old Java Objects) and POJIs (Plain  
> Old Java Interfaces).
>
> WebObjects Frameworks are already well layered and don't depend on  
> EJBs, a source of needless complexity from what I've been reading.
>
> IoC (Inversion of Control), to the extent that I understand the  
> concept, has already been implemented in the WO frameworks, where  
> necessary to retain the good behavior of the layering, through  
> delegation and delegation predated WO as a pattern.
>
> If you're coming out of a J2EE/JavaBeans world, I think you'll find  
> that the basic WO frameworks have already addressed many of the  
> issues that have led to the Open Source movements for augmenting  
> J2EE, namely poor design of the Java J2EE frameworks.
>
> The primary driving forces in the WO world for open source  
> frameworks and IDEs are two-fold:
>
>   * Apple's unwillingness/inability to publish a path forward (Will  
> WO be here in 2 years? Will it still be available to me? What will  
> it look like? How much will I have to change that which I build now  
> to interact with it?)
>
>   * Apple's migration to support of WO for development/deployment  
> only on Apple hardware. We can still develop and deploy on Windows  
> systems, but they're no longer supported by Apple. I think it will  
> soon be true that the only way to continue development on non-Apple  
> platforms will be through Open Source projects, such as
>
> Of course, if you talk to the Project Wonder people, there is the  
> third driving force that "...WO can be made better, and we, the  
> developers of the Project Wonder frameworks, are doing just that."  
> Given many of the facilities that Project Wonder adds to WO, I  
> think they have a legitimate case.
>
> Regarding Automated testing, there are two levels to deal with:
>
>   * Unit testing - as mandated by many of the modern light  
> methodologies (e.g. XP). This is well implemented for WO with a  
> framework called WOUnitTest developed by Shin Ogino and Christian  
> Pekeler. (go to http://wounittest.sourceforge.net/ for more  
> information).
>
>   * Component testing - This is a much harder problem, rendered  
> only a little less necessary by good unit tests. I think that it's  
> still best handled by commercial web page testing packages, but  
> their interface to your code tends to be strictly through HTTP, so  
> should not affect your decision.
>
> I would like to suggest trying a couple small projects in WO before  
> deciding. Unfortunately, that advice drives you head first into  
> WO's rather steep learning curve.
>
> Which takes me to my parting thought. Now that I've provided some  
> advice out of my ignorance, I'm sure others who have used WO/Wonder  
> and Spring/Hibernate/Tapestry will step in and provide better  
> guidance, if not only to shoot some of these ideas down.  :-)
>
> Regards,
> Jerry
>
>
> --
> __ Jerry W. Walker, Partner
>     C o d e F a b, LLC - "High Performance Industrial Strength  
> Internet Enabled Systems"
>     [email protected]
>     212 465 8484 X-102  office
>     212 465 9178        fax
>
>
> _______________________________________________
> WebObjects-talk mailing list
> [email protected]
> http://www.omnigroup.com/mailman/listinfo/webobjects-talk
>

-- 
Practical WebObjects - a book for intermediate WebObjects developers  
who want to increase their overall knowledge of WebObjects, or those  
who are trying to solve specific application development problems.
http://www.global-village.net/products/practical_webobjects