Scott T Weaver 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.On Tue, 2004-05-18 at 17:06, Ate Douma wrote:
Scott T Weaver wrote:
Here is my approach for "merging" in my branch changes into HEAD.
I have gone through many iterations on updating the way build/deploy our
components. I ended up coming to the conclusion that simple is better. Since many things have changed since I created my branch, I thought it
best that I replicate my approach by duplicating what I did in my branch
and not directly patching or merging. That way I can do little,
incremental changes, test them and commit (the way it should have been
done in the first place).
+1
Some other things I will be doing:
1. I propose we DO NOT (yes, I said NOT) use containers in component test cases as it really is not a requirement since all components can should be usable/testable with out a container. All that is need is mocking of the dependencies. I have started using jMock for this instead of having to create the mock objects by hand (jMock uses a dynamic proxy approach).
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
I realize that we need to make sure that our components are working with 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.
That would be my proposal then: not defining a standalone integration goal (although it can be useful) for now but running these data model test cases conditional based on a property setting. I'm not sure if that is easily or even possible to realize though.
The problem that might create is that this new integration subproject probably will depend on every component tested. Can you guarantee that problems with one component won't block testing another (including its own integration test)?
That is why I suggest we develop a new set of "integration" unit tests
that are run by a separate build command against a live environment. Here is a radical idea, how about a subproject within the Jetspeed 2
source tree that is dedicated to nothing but integration testing?
Another plus of this approach is that back-end specific (read RDBMS information) is only present in one location as opposed to how it is now with OJB artifacts and DS info replicated all over the place a myriad of times.
Although getting rid of DS and OJB configurations scattered all over the place would be nice I wouldn't trade them for increased dependencies.
2. NanoQuickDeployer is an evil hack that I created out of sheer
laziness and I ought to be shot, drawn and quartered, flayed, etc. for
introducing it. So, I propose we delete it and just manually assemble
components in jetspeed.groovy. There are two reasons for this:
1. This should alleviate the issue of components starting 2 or 3 times. 2. We can see EVERYTHING that is being assembled into the engine by just looking in one location.
+1
I won't start this until i get some feedback from the list.
As I understand merging your branch will result in many, many changes. Can you give a prediction how long it will take you to do this? Days, weeks?
Hopefully days as I have already done this once before, I am using the XP "Courage" approach to merge my branch.
Although I fully support your approach of doing it in small steps, it also starts a possibly lengthy period in which the whole codebase is in flux. Doing other modifications during this period might become bothersome.
This shouldn't be to bad as I while be "compnentizing" one logical set of components at time, testing them and committing them. I will start with the components least likely to change for out under me, like ID Generator, rewriter and locator and move on to more "dynamic" ones like Registry, Security and Aggregator.
I surely don't want to give the impression I'm trying to push you because I'd rather have it done slowly and successful than too quickly with lots of complications. But I do think that it is important to have this period as short as possible.
+1. I have already burnt a lot of time already in my branch, however it was good learning experience for me allowing me to identify what works, what works well and what is total crap. It was kinda like sitting, up meditating on a mountain...okay now I am just talking stupid ;)
And maybe it might be wise to tag the current code base before this merge is started so there is some common ground to compare with and/or work on. I've no problem having to develop against an older version and have to do some merging or refactoring myself afterwards. For that I would like to have a way of retrieving that version from cvs and not depend on a locally archived version.
+1. Any ideas on what we want to call the branch?
Regards,
Ate
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
