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/
