You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Grzegorz Kossakowski <gr...@tuffmail.com> on 2007/08/11 12:50:05 UTC
Introduction of cocoon-container core module
Hello,
I'm playing with COCOON-2110 at the moment and run into problem with writing test for new functionality.
Our current code is messed a little when it comes to modules affilation. For example, our
Avalon-Spring bridge[1] code is in cocoon-sitemap-impl module. Tests[2] for functionality
(PreparedVariableResolver class) belonging to cocoon-sitemap are in cocoon-core. This two examples
are the most prominent but there are some more.
I'm especially interested in PreparedVariableResolverTestCase because I want to write tests for my
code handling new expression evaluation. I need dependency on cocoon-expression-language-impl in
cocoon-core, of course. The problem is that cocoon-expression-language-impl already depends on
cocoon-core because it makes use of o.a.c.CocoonTestCase defined in core. This introduces an cyclic
dependency.
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.
This way we should have cleaner dependencies and more freedom when it comes to moving stuff. I've
already played with such approach locally and as for now it seems to work well.
Thoughts? Objections?
PS. I'll start to commit this stuff really soon because I need it know. If someone objects and give
other solution I'll be fine to revert my work.
[1]
http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/java/org/apache/cocoon/core/container/spring/avalon/
[2]
http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-core/src/test/java/org/apache/cocoon/components/treeprocessor/variables/
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: Introduction of cocoon-container core module
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Grzegorz Kossakowski skrev:
> Daniel Fagerstrom pisze:
...
> 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?
Override
AbstractDependencyInjectionSpringContextTests#getConfigLocation() in
your module specific abstract test class with the following:
protected String[] getConfigLocations() {
return new String[] { getClass().getName().replace('.', '/') +
".spring.xml" };
}
Or put the code in some common abstract test class.
...
>>> 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 and there is no problem with FOMTestCase and
> dependencies of cocoon-expression-language-impl are much more cleaner.
> I'm feeling good because of it. ;-)
:)
/Daniel
Re: Introduction of cocoon-container core module
Posted by Grzegorz Kossakowski <gk...@apache.org>.
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.
Agreed.
> 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 and
there is no problem with FOMTestCase and dependencies of cocoon-expression-language-impl are much
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.
Agreed.
[1]
http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-core/src/test/java/org/apache/cocoon/AbstractTestCase.java
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: Introduction of cocoon-container core module
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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
>> http://static.springframework.org/spring/docs/2.0.x/reference/testing.html.
>
> 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
AbstractDependencyInjectionSpringContextTests.
> 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
>> http://marc.info/?l=xml-cocoon-dev&m=116740983716752&w=2 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.
/Daniel
> [1]
> http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-expression-language/cocoon-expression-language-impl/src/test/java/org/apache/cocoon/components/expression/ExpressionTestCase.java
>
> [2]
> https://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-expression-language/cocoon-expression-language-impl/src/test/java/org/apache/cocoon/environment/FOMTestCase.java
>
>
Re: Introduction of cocoon-container core module
Posted by Grzegorz Kossakowski <gk...@apache.org>.
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.
> 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
> http://static.springframework.org/spring/docs/2.0.x/reference/testing.html.
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?
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?
Moving tests of expressions to cocoon-sitemap-impl is quite weird for me. Am I only one feeling that?
>> 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.
>
> 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
> http://marc.info/?l=xml-cocoon-dev&m=116740983716752&w=2 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.
[1]
http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-expression-language/cocoon-expression-language-impl/src/test/java/org/apache/cocoon/components/expression/ExpressionTestCase.java
[2]
https://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-expression-language/cocoon-expression-language-impl/src/test/java/org/apache/cocoon/environment/FOMTestCase.java
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: Introduction of cocoon-container core module
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Grzegorz Kossakowski skrev:
> Hello,
>
> I'm playing with COCOON-2110 at the moment and run into problem with
> writing test for new functionality.
>
> Our current code is messed a little when it comes to modules affilation.
> For example, our Avalon-Spring bridge[1] code is in cocoon-sitemap-impl
> module. Tests[2] for functionality (PreparedVariableResolver class)
> belonging to cocoon-sitemap are in cocoon-core. This two examples are
> the most prominent but there are some more.
>
> I'm especially interested in PreparedVariableResolverTestCase because I
> want to write tests for my code handling new expression evaluation. I
> need dependency on cocoon-expression-language-impl in cocoon-core, of
> course. The problem is that cocoon-expression-language-impl already
> depends on cocoon-core because it makes use of o.a.c.CocoonTestCase
> defined in core. This introduces an cyclic dependency.
Why are you depending on CocoonTestCase for testing the expressions?
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
http://static.springframework.org/spring/docs/2.0.x/reference/testing.html.
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.
> 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.
> This way we should have cleaner dependencies and more freedom when it
> comes to moving stuff. I've already played with such approach locally
> and as for now it seems to work well.
>
> Thoughts? Objections?
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
http://marc.info/?l=xml-cocoon-dev&m=116740983716752&w=2 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.
/Daniel