On May 19, 2004, at 8:07 AM, Ate Douma wrote:
I think we're dealing with two different test cases here. One is for testing the persistent data model and the other is for testing the logic of the component using the data model.I realize that we need to make sure that our components are working with
Like David Taylor, I would object at removing *all* container usage in test cases because I also see the need and benefit of concrete database interaction testing. Don't forget, Jetspeed can and will be used with many different databases, each with there own behavior. OJB/Torque can differentiate for that. I don't see how mocking can ever deal with all those variations
their associated back end systems and what not, however, when you start
developing unit tests that test solely for idiosyncrasies of those back
end systems, a good example being the TestRegistryDirect1 & 2, your unit
test looses focus of its true purpose which is testing the logic of the
component itself.
I agree that the second type doesn't need to also test the real back end integration. But only if the first type is done also. If current test cases mix these type of tests I'm +1 on separating them as you proposed. Furthermore, data model changes occur certainly less as logic changes (once a model is stable) so running those test cases every time alongside the logic test cases might just as well be optional.
Many of the test failures we had were in the specific O/R mapping for those specific component impls.
IMO Components like the Registry component's purpose is mostly O/R mapping related, and the component core functionality should be tested as a part of the build
I would very much like to see a system test sub-project for testing complex test cases and performance
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
