[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[hyades-dev] Meeting minutes for Hyades Execution Histories Model Subgroup Meeting on May 9, 2003
|
Attached (and as included text) are
the meeting minutes for the Execution Histories Model Subgroup meeting
from 09-May-2003. Also attached is the cat file for this section of the
model. This is intended to be available in an up-coming drop of Hyades.
Regards,
ashish
------------------------------------------------------------------------
Ashish K. Mathur
Advisory Software Engineer
IBM - SWG - Rational Division
Phone: (919)845-3213 Fax: (919)845-3250
Email: akmathur@xxxxxxxxxx
---------------------------------------------------------------------------------------------------------------------------------------------------------------
Execution Histories Model Subgroup, 9-May-2003
Attending
---------
Ashish Mathur
- IBM Rational Raleigh
Gian Franco Bonini
- SAP
Marcelo Paternostro
- IBM Toronto
Kent Siefkes
- IBM Rational Raleigh
Discussion
-------------------------
One of the goals at the end of this week
was to finalize the execution
histories model and we agreed we have something
decent at the end of this meeting.
Finalizing the model
- Marcelo: Change the 'status' attribute
in the TPFStatusEvent to 'verdict'.
All agreed.
- Ashish: Change the 'TPFStatusEvent'
to 'TPFVerdictEvent'. All agreed.
- Kent: Should be able to provide
a reason when a verdict/invocation
event is not successful. Agreed
on the need to have an attribute to hold
the reason for a failed verdict
event or an invocation event.
- Introduced
a 'reason' attribute to TPFVerdictEvent to allow
the
specification of a reason for the verdict. The possible values
for
the reason are listed in the TPFVerdictReason enumeration.
Please
refer to the model for details.
- When
another TestCase is invoked, lot of things could go wrong.
In
some cases, the invoked TestCase may have its own execution
history
created while in other cases, the invocation may never
have
gotten to create one. In either case, a status of the
invocation
is needed, which would be separate from a verdict.
Added
attribute 'status' to the TPFInvocationEvent to indicate
what
happened when the TestCase was invoked. The status could
be
one of successful, unsuccessful or unattempted.
- Also,
we need to be able to provide a reason for the failure,
if
available. The 'reason' attribute of the TPFInvocationEvent
will
provide such a reason. Possible reasons are listed in the
TPFInvocationReason
enumeration.
- Kent: Should the Reasons be further
specialized based on the
verdict/status? Should we
have TPFErrorReason, TPFFailureReason,
TPFInconclusiveReason based
on the verdict, extend TPFVerdictReason?
And have TPFUnsuccessfulReason
and TPFUnattemptedReason extend from
TPFInvocationReason?
- Agreed
to not do that since it would lead to enough duplication
and in the
interest of keeping things simple. If there arises a
strong reason
in the future, this could be considered.
- Marcelo: All attributes in the
model have to be
- public
- lowercase
(with subsequent words starting with capital letters)
- of
the 'String' data type
- Gian Franco: Do we have to specify
even attributes like 'timestamp'
with a String data type when
they are naturally either long or integer?
- Agreed to change 'timestamp' to 'Long' data type.
- Marcelo: Past input was that a
test suite is not associated with an
execution history. Need to
re-visit the association of execution
histories with test suites
since a test suite may have complex behavior.
- Marcelo: The reference within execution
histories of testcases need
to be a solid EMF design.
Marcelo to take this up with the EMF team.
- Marcelo: Creating an execution
history should not make the TestCase
'dirty' (modified with a need
to save). Suggesting the relationship
between Execution Result and
TestCase to be either
- Unidirectional
(recommended)
- Transient
- based
on a query mechanism
- Agreed that we have a decent model
for execution histories.
Action Items:
-----------------
1. Have the modified class diagram available
- Ashish to send Marcelo
2. Publish the modified model and make
it available in the next drop - Marcelo
3. Re-visit Execution Histories for Test
Suites. - Ashish to add to agendaAttachment:
common.cat
Description: Binary data
Execution Histories Model Subgroup, 9-May-2003
Attending
---------
Ashish Mathur - IBM Rational Raleigh
Gian Franco Bonini - SAP
Marcelo Paternostro - IBM Toronto
Kent Siefkes - IBM Rational Raleigh
Discussion
-------------------------
One of the goals at the end of this week was to finalize the execution
histories model and we agreed we have something decent at the end of this meeting.
Finalizing the model
- Marcelo: Change the 'status' attribute in the TPFStatusEvent to 'verdict'.
All agreed.
- Ashish: Change the 'TPFStatusEvent' to 'TPFVerdictEvent'. All agreed.
- Kent: Should be able to provide a reason when a verdict/invocation
event is not successful. Agreed on the need to have an attribute to hold
the reason for a failed verdict event or an invocation event.
- Introduced a 'reason' attribute to TPFVerdictEvent to allow
the specification of a reason for the verdict. The possible values
for the reason are listed in the TPFVerdictReason enumeration.
Please refer to the model for details.
- When another testcase is invoked, lot of things could go wrong.
In some cases, the invoked testcase may have its own execution
history created while in other cases, the invocation may never
have gotten to create one. In either case, a status of the
invocation is needed, which would be separate from a verdict.
Added attribute 'status' to the TPFInvocationEvent to indicate
what happened when the testcase was invoked. The status could
be one of successful, unsuccessful or unattempted.
- Also, we need to be able to provide a reason for the failure,
if available. The 'reason' attribute of the TPFInvocationEvent
will provide such a reason. Possible reasons are listed in the
TPFInvocationReason enumeration.
- Kent: Should the Reasons be further specialized based on the
verdict/status? Should we have TPFErrorReason, TPFFailureReason,
TPFInconclusiveReason based on the verdict, extend TPFVerdictReason?
And have TPFUnsuccessfulReason and TPFUnattemptedReason extend from
TPFInvocationReason?
- Agreed to not do that since it would lead to enough duplication
and in the interest of keeping things simple. If there arises a
strong reason in the future, this could be considered.
- Marcelo: All attributes in the model have to be
- public
- lowercase (with subsequent words starting with capital letters)
- of the 'String' data type
- Gian Franco: Do we have to specify even attributes like 'timestamp'
with a String data type when they are naturally either long or integer?
- Agreed to change 'timestamp' to 'Long' data type.
- Marcelo: Past input was that a test suite is not associated with an
execution history. Need to re-visit the association of execution
histories with test suites since a test suite may have complex behavior.
- Marcelo: The reference within execution histories of testcases need
to be a solid EMF design. Marcelo to take this up with the EMF team.
- Marcelo: Creating an execution history should not make the testcase
'dirty' (modified with a need to save). Suggesting the relationship
between Execution Result and testcase to be either
- Unidirectional (recommended)
- Transient
- based on a query mechanism
- Agreed that we have a decent model for execution histories.
Action Items:
-----------------
1. Have the modified class diagram available - Ashish to send Marcelo
2. Publish the modified model and make it available in the next drop - Marcelo
3. Re-visit Execution Histories for Test Suites. - Ashish to add to agenda