RE: [hyades-dev] Test Model updates

[Michael.Norman@xxxxxxxxxxxxx]

I can't understand why the Junit source code is being put into the same 
place in the model as the Hyades behaviour.
 
In the proposed simple integration of Junit, in our view of the world, 
the Hyades Test tests the Junit layer, it doesn't tell you anything 
about the underlying system under test. The Junit tests are thus not 
behaviours, they are SUTs.  They happen to be a proxy for a real SUT, 
but the Test Model doesn't deal with that issue.  Similarly from a UI 
perspective when you drill down as far as the SUT in the editor, you 
will fire up a source code editor irrespective of whether you have hit a 
piece of Junit code or a piece of java code which isn't Junit.
 
Am I missing something, and does it matter?
 
Mike

-----Original Message-----
From: slucio [mailto:slucio@xxxxxxxxxx]
Sent: Tuesday, April 29, 2003 11:51 PM
To: hyades-dev
Subject: [hyades-dev] Test Model updates




As discussed during our last Test Model meetings, I have added the 
concepts of Artifact and DeploymentSpec into the common/configuration 
package. 
  
Based on discussions with Marcelo and Joe, I did some changes in the 
area of behaviors too. The main issue we are trying to solve is about 
persistence split between Test Suite/Test Case/Behavior. As raised by 
Marcelo, the Eclipse paradigm for editors is based on resource editing. 
Therefore, if we want to have an editor for the meta-data of Test 
Suites/Test Cases and have different editors for behaviors we need 
separate resources. The problem is very similar for vendors who would 
not yet support behavioral modeling in Hyades: An example is the JUnit 
thread that we want to have for Hyades v1.0, where we expect to have the 
behavior of the test persisted in a java file. 
  
The modifications are: 
- Introduction of a BVRInteraction class (It existed in the original UML 
2.0 behavioral model, but was removed later because perceived as a 
not-required step, since Hyades would only support the Interaction 
metamodel (no statemachines, etc.). See 
common/behavior/fragments/InteractionOccurences diagram. 
- Introduction of two attributes in the TPFBehavior class: 
resource: a URL to the resource where the behavior is stored 
location: stores the location within the behavior resource where the 
behavior is (to address the case where multiple behaviors would be 
stored in one resource). 
See common/testprofile/Main diagram. 
  
Every change I did is marked in red and when required annotated. These 
modifications will be discussed during the next Test Model meeting. 
  
Serge