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/
