cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: Introduction of cocoon-container core module
Date Tue, 14 Aug 2007 08:54:15 GMT
Daniel Fagerstrom pisze:
> I think that the abstract test cases should try to follow the dependency 
> structures of the modules they are testing. But we are not there yet for 
> the split Cocoon core.


> Yes, I would suggest doing that in a setUp() method. Also it might be 
> more appropriate to call it DefaultExpressionFactoryTest as it unit 
> tests that particular class.

Done in r565521.

> If you feel the need of integration testing. I.e. testing the actual 
> bean configuration files and bean graph that the module exports, you 
> could have a separate test case that extends the 
> AbstractDependencyInjectionSpringContextTests.

We use very nice convention for configuration files of TestCases, see[1] especially 
createBeanFactory method. If we use AbstractDependencyInjectionSpringContextTests we will
loose this 
nice and useful convention.

Any idea about it?

>> FOMTestCase tests if expressions work well with ObjectModel and 
>> environment data. According to what you said, I should move this test 
>> to cocoon-sitemap-impl, right?
> Yes. Then I would propose that you have some test code that in the 
> cocoon-expression-impl that do more specific testing of the 
> ObjectModelImpl where you set up the contents manually in the test case.

I see.

>> Moving tests of expressions to cocoon-sitemap-impl is quite weird for 
>> me. Am I only one feeling that?
> First I would propose moving the CocoonEntryObjectProvider to 
> cocoon-sitemap-impl. By doing that you get rid of the 
> cocoon-expression-language-impl dependency on cocoon-pipline-api, which 
> simplifies the dependency graph and makes cocoon-expression-language 
> more useful outside Cocoon.
> Then it would probably feel quite natural to test accessing parts of the 
> Cocoon object model in the cocoon-sitemap-impl.
> Testing the expression functionality is of course most natural to do in 
> the expression module.

I see it know! It's that eureka moment! :-)
I've done what you advised last commits. Now CocoonEntryObjectProvider is in cocoon-sitemap-impl
there is no problem with FOMTestCase and dependencies of cocoon-expression-language-impl are
more cleaner. I'm feeling good because of it. ;-)

>> I had the same goal (decreasing the number of dependencies) in mind 
>> but chose wrong approach. Even though I think we should move bridge to 
>> cocoon-container I won't work on it now because it does not solve my 
>> current problems.
>> I'll get back to it when time permits.
> Sounds good. It would be really nice to get to a point where it is an 
> optional module just needed for users that hasn't Springified their 
> custom components. But it will take some work to get there.



Grzegorz Kossakowski

View raw message