| [hyades-dev] Some Test Model & UI progress |
Hi all.
Marcelo, Serge and I had a very productive discussion this afternoon, and I'd like to summarize some conclusions that were drawn:
1) We again debated the ownership of TestCase by TestSuite, and came to a very nice compromise. While a TestCase is owned by a TestSuite, we will break the aggregation-by-value of the TestCase's behavior. In fact, we will model neither the TestSuite's behavior nor the TestCase's behavior as owned by the TestCase or the TestSuite -- behaviors will be persisted in their own resources. This solves many of the issues we have wrestled with in the TestModel group and also in the UI team. When envisioning the use case where a behavior is not modeled using the test model, in a JUnit source file, for instance, it is clear that the behavior is persisted in a separate resource. This works equally well if the behavior is modeled in the Test Model, as opening the TestCase behavior requires a new editor to be opened (this is an extension point), and in Eclipse this would imply that a separate resource is being opened. Lastly, this will drive a clear separation between our U2TP Test Model implementation and whatever format the implemented behavior may take for a given TestCase type. In short (or perhaps in long), we found many reasons to like this approach.
2) Based on the above, we identified and refined another extension point for Hyades -- a Behavior Editor Adapter (the name will certainly change to something better.) When a user gestures to open a TestCase behavior, the Hyades TestTool will look up the Behavior Editor Adapter that is registered for this TestCase type (*). It will hand that adapter the two attributes that will be stored for the behavior of that TestCase -- a URL (relative to the workspace for Hyades 1.0) and a behavior location (a string that specifies the behavior's location within the resource referenced by the URL -- can be empty). The adapter is then responsible for opening the resource and navigating to the specified location. The same flow will also apply for opening a TestSuite behavior.
Please post any concerns or comments that you have on these issues. We'll review them in the upcoming Test Model and UI meetings as well.
Thanks,
--Joe
(*) In truth, we will first check the preferences to see if the user has specified a preferred adapter. It's not clear to me whether we will expose the Behavior Editor Adapter separately, or incorporate it into a larger adapter that encompasses other type specific extensibility points -- it's somewhat of a user experience question as well. But the point is that we are not mandating that one and only adapter will exist for a given type. It is expected that some adapters will be shared (such as the one that knows how to take a java source file and open it, scrolled to a specified method), and it is also allowed that a given type will be supported by more than one adapter (in which case we'll observe the preference if it is specified, and we can choose a strategy for dealing with the case in which a preference is not specified.) We could also support an Open With command from the element in this case.
Joe Toomey
Senior Staff Software Engineer
Rational Software
IBM Software Group
tel: (781) 676-7668
fax: (781) 676-7640