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
