Re: Testing WO code

On Aug 2, 2005, at 12:55 AM, Mark Doyle wrote:
>
>
> I am going to invite Lenny to comment here (I don't think he reads 
> webobjects-talk)...

No I hadn't been reading webobjects-talk so I apologize for the late 
entry.

>
> On Jul 18, 2005, at 4:30 PM, Chuck Hill wrote:
>>
>> 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
>>


I pretty much agree here. We don't use Spring to do much in the 
application layer(WO layer). It's my opinion also that the bulk of your 
logic belongs outside of your WO components. The layered architecture 
we(and many others) are using is to basically split our code into a 
model layer(POJO model classes with no dependencies on the persistence 
framework), a data access layer(where the persistence code is), and a 
service layer(where the majority of the business logic goes, client of 
the data access layer).  The real benefits we get from Spring are 
mostly in the data access and persistence layers. For example, you can 
configure your bean definitions to wire up proxy implementation of your 
interfaces that do stuff like hibernate session management(open and 
closing) for your data access objects and declarative transaction 
management(demarcation) for your service layer. As far a unit testing 
goes, its not Spring itself that helps here, but the fact that your 
objects are expecting to have their collaborators injected(as opposed 
to creating them internally or looking them up via static factory 
methods or JNDI) and these collaborators are defined as interfaces. 
Normally Spring would wire everything up with real implementations, but 
in the context of unit testing, you can create stub or mock 
implementations for the collaborators of the and just plug them in via 
the same means Spring would( constructor or setter methods).  A common 
case would be a service layer class that uses some data access objects 
to look up and save data. By plugging in mock or stub implementations 
of the data access classes, you can test the service class without 
touching the database.  EasyMock is nice here because it will create 
the mock implementations automatically.


>>
>> 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 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).

The POJO model classes in Hibernate would not have any complication, 
overhead, or dependency on the persistence framework at all. It's a lot 
closer to transparent persistence. This is contrary to EOF where your 
model classes extend from EOF classes and are tightly bound to 
EditingContexts. Its a bit difficult to create a test outside of a WO 
application because you have to make sure you have your classpath setup 
with all the EOF frameworks, and you have to load all your 
eomodels(EOPrototypes first). I think you may even need a database to 
connect to. We do it successfully, but there was a bunch of setup(not 
all of which I remember right now) involved. Maybe that's some of the 
stuff that WOUnitTest takes care of, but the point is that if they were 
really POJO objects, they wouldn't need anything special.

.
>>>
>>> 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.
>>>
Personally, I think that Delegation can provide some of the same 
benefits as IoC. In testing they can both be used to change normal 
execution so that a specific class can be tested in isolation, but 
delegation often requires you to know far more about the actual 
implementation of collaborators. For example, in EOF, you may have to 
know how to gain access to the lower level stack objects to plug in an 
editing context delegate and a DatabaseContext delegate to eliminate 
access to the database. Also, to use the delegate pattern yourself 
requires a lot of thought about what hooks you should provide and this 
kind of violates YAGNI. With IoC you really don't have to do anything 
special.

>>>
>>> Regards,
>>> Jerry
>>>
>>>

> I am a bit lost. Why using WebObjects in combination with
> Hibernate??? To make life more challenging perhaps?

I won't go into reasons to switch from EOF to Hibernate, but the main 
we are still using WO with Hibernate is because that is what our 
developers are familiar with and that is what all our apps are already 
developed in. It wasn't that hard to substitute Hibernate for EOF. From 
the perspective of our WO display code, there is often little 
difference, but to rewrite all our front end apps would be a much 
bigger undertaking.

> It is a long discussion I am prepared to have only when a lot of beer
> is available, but it is my strong believe (based on long years of XP
> projecting) that mock objects do more harm then good. We use WOUnit
> with some extensions that fit our frameworks, and we are very happy
> with it....
>
> -- georg --

I agree with what Chuck wrote earlier about functional and integration 
tests having their place, but we've found mock objects to be a very 
useful and effective tool for lightweight unit testing and test first 
development.

> Why was integration difficult?
>
> Why did you feel the need to use Spring?  Surely, Hibernate could just 
> replace EOF.
>
>
> Cheers,
> Ashley.

We decided to use Spring along with Hibernate for the benefits 
previously mentioned. Although the basic Spring IoC is great, the 
Hibernate integration was a bit sticky, especially using "Long 
Hibernate Sessions" which are not really supported out of the box with 
Spring.

-lenny