RE: [hyades-dev] Test Model updates

[Michael.Norman@xxxxxxxxxxxxx]

Joe

The Real-SUT vs Pseudo-SUT thing is obviously causing concern, but it's 
just how we bind the edge of the model onto the external environment.  
You don't have to make any changes to the model to accommodate it.  
Pseudo-SUTs are not just a Scapa Special (cf. TRI), they express some 
behaviour in a wrapper around the real SUT rather than in the test model 
itself, typically because it is more convenient to do so or, in the case 
of conformance testing, so that the test stands alone - the SUT provides 
an interface for driving itself in the manner required by the 
conformance test.

The argument I am making is that you can view JUnit as a wrapper around 
a Real SUT, and thus as a Pseudo SUT, and thus you can bind it into the 
model at that point.  The behaviour you define in the test case driving 
JUnit can be as complex or nonexistent as you like. Ulimately Junit is 
Java code just like a Java SUT. The question in my mind is thus why do 
we need two points in the model at which we link to pieces of Java code 
which are logically both (Pseudo)-SUTs?

All I think I am suggesting is that you move the two attributes proposed 
for the TPFBehavior class (i.e. resource and location) onto the TPFSUT 
and use them to point to the JUnit Source Code.

Doesn't what I am suggesting look identical to the way it was done in 
ComponentTest?
Doesn't your editor problem go away?

I'm keen to air this in public, but we should try and come to a 
resolution in private.

Mike

-----Original Message-----
From: jtoomey [mailto:jtoomey@xxxxxxxxxxxx]
Sent: Wednesday, April 30, 2003 5:12 PM
To: hyades-dev
Subject: RE: [hyades-dev] Test Model updates


Hi Mike,

First, the JUnit source code is not being put into the model.  In the
example Serge described, a reference to the source code is being put in 
the
model.  I think that was understood, but I just wanted to be clear.

It has been agreed in the Test Model group on many occasions that we 
will
not require test behavior to be modeled.  Requiring a test tool vendor 
to
model their test behavior is a barrier to adoption of Hyades as a 
framework,
and it has been our explicit goal in the Test Model group to support 
both
modeled test behaviors, and also test behaviors that are external to the
test model.  The changes that Serge described allow a user of the test 
model
who does not want to model their test behavior to indicate where their 
test
behavior is stored.

I understand your proposal of a Pseudo-SUT, and there is nothing in the 
Test
Model to preclude you from using that approach.  However, to mandate 
such an
approach seems to mandate the modeling of the test behavior, since, if 
the
external test is really considered an SUT, you must at a minimum specify 
how
you will stimulate that SUT.  We have never discussed the Pseudo-SUT as 
a
concept that would be modeled or exposed by the test model, which is 
notable
since you are on the test model team.  The first mention of the 
Pseudo-SUT
(aside from discussions of a testability interface during the 
face-to-face
meeting) was in your overview document that you sent around last week.  

I'm not convinced that the Pseudo-SUT approach is something that should 
be
presented or dictated by the test model, since the model as it stands 
can
support a Pseudo-SUT pattern, but is still general enough to allow a 
more
mainstream view of the test (i.e. the test is a test, not an SUT.)  If 
you
disagree, then we should discuss it further, but since the goal is to 
shut
down the test model next week, this clearly seems to be a post-1.0
consideration.

--Joe

Joe Toomey
Senior Staff Software Engineer
Rational Software
IBM Software Group
tel: (781) 676-7668
fax: (781) 676-7640



> -----Original Message-----
> From: Michael.Norman@xxxxxxxxxxxxx 
> [mailto:Michael.Norman@xxxxxxxxxxxxx] 
> Sent: Wednesday, April 30, 2003 11:29 AM
> To: hyades-dev@xxxxxxxxxxx
> Subject: RE: [hyades-dev] Test Model updates
> 
> 
> 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 
> 
> 
> 
> _______________________________________________
> hyades-dev mailing list
> hyades-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/hyades-dev
> 
_______________________________________________
hyades-dev mailing list
hyades-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/hyades-dev