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
