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
