cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Introduction of cocoon-container core module
Date Sat, 11 Aug 2007 13:10:15 GMT
Grzegorz Kossakowski skrev:
> Daniel Fagerstrom pisze:
>> Grzegorz Kossakowski skrev: Why are you depending on CocoonTestCase 
>> for testing the expressions? 
> I think it's mostly a matter of convenience. CocoonTestCase or 
> ContainerTestCase sets up almost everything I need so I can write good 
> test in few lines. As we see, it's not perfect because it introduces 
> lots of dependencies.

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.

>> AFAICS, you are not needing anything from CocoonTestCase at all for 
>> testing expressions. Most of the testing can be done on the bean level 
>> with pure Junit and for the integration tests, where you want to test 
>> the configuration files, I would assume that 
>> org.springframework.test.AbstractDependencyInjectionSpringContextTests 
>> would do what you need. Take a look at testing with the Spring 
>> framework 
> Will read it now.
>> If you feel like testing how the expression mechanism works in a 
>> complete sitemap environment, that is part of testing the sitemap 
>> rather than testing the expressions and should be done in the sitemap 
>> or core modules.
> Daniel, could you take a look at these[1][2] test cases and give an 
> advice what to do with tem? I'm still learning an some real life example 
> would help me to grasp directions.
> ExpressionTestCase tests if ExpressionFactory properly returns compiled 
> expression for all three expression languages. Do you suggest to 
> manually inject all compilers to ExpressionFactory?

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.

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 

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

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

>>> Similar situation occurs when I want to move 
>>> PreparedVariableResolverTestCase to the cocoon-sitemap-impl module. 
>>> Having said that I would like to propose introduction of new core 
>>> module 'cocoon-container' where I would move our Avalon-Spring 
>>> bridge, base TestCases and other related stuff.
>> Having an own module for the Avalon-Spring bridge seem like a good 
>> idea (although it probably require some refactoring to get reasonable 
>> dependencies). But I don't see why it should contain base test 
>> classes. As we are moving away from Avalon we should strive to remove 
>> the dependencies on the Avalon-Spring bridge successively. So I really 
>> don't want the expression abstractions depend on the Avalon-Spring 
>> bridge.
> Only tests (scope=test in Maven) would depend on bridge but I agree with 
> your standpoint. I also realized that bridge depends on lots of stuff 
> from Cocoon, especially on components interfaces. That means won't 
> really clean dependencies but I think we don't have to strive for it. 
> All in all, our bridge is temporary (although, long-term) solution.

I don't see any problems with letting the bridge depending on lots of 
stuff as fewer and fewer Cocoon modules depend on the bridge.

>> The main thing with dependencies is that they should be few. The 
>> reusability of a module decreases rapidly with increasing number of 
>> dependencies. Please take a look at 
>> for 
>> understanding the goals with the splitting up of the Cocoon core in 
>> smaller modules. The core split is in no way finished so you are of 
>> course welcome to continue the work. But please respect the main 
>> direction of *decreasing* the number of dependencies.
> 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.


> [1] 

> [2] 


View raw message