Introduced EiffelTestCaseTriggeredEvent and EiffelTestCaseCanceledEvent #134
Conversation
| [EiffelIssueVerifiedEvent](../eiffel-vocabulary/EiffelIssueVerifiedEvent.md) | ||
| __Optional in:__ None | ||
| __Legal targets:__ [EiffelArtifactCreatedEvent](../eiffel-vocabulary/EiffelArtifactCreatedEvent.md), | ||
| [EiffelCompositionDefinedEvent](../eiffel-vocabulary/EiffelCompositionDefinedEvent.md) | ||
| __Multiple allowed:__ No | ||
| __Description:__ Identifies the Item Under Test: what has been tested and/or been verified to address an issue. | ||
| __Description:__ Identifies the Item Under Test: what is being tested and/or been verified to address an issue. |
There was a problem hiding this comment.
It should be different tense depending on the case, though. For TCT it something about to be tested, for IV it's something that has been verified. But the sentence is poorly structured, will improve it.
| ### data.testCase | ||
| __Type:__ Object | ||
| __Required:__ Yes | ||
| __Description:__ Identification of the executed test case. |
There was a problem hiding this comment.
Identification of the test case to be executed.
| #### data.testCase.id | ||
| __Type:__ String | ||
| __Required:__ Yes | ||
| __Description:__ The unique identity of the executed test case. |
There was a problem hiding this comment.
The unique identity of the test case to be executed.
| #### data.testCase.version | ||
| __Type:__ String | ||
| __Required:__ No | ||
| __Description:__ The unique version of the executed test case identity. Where this property is not used it is assumed that test cases are not version controlled. |
There was a problem hiding this comment.
The unique version of the test case identity to be executed.
| #### data.testCase.uri | ||
| __Type:__ String | ||
| __Required:__ No | ||
| __Description:__ A location where a description of the test case can be retrieved. To the extent that multiple versions of the same test case co-exist, this property SHALL identify the exact version executed. |
There was a problem hiding this comment.
the exact version to be executed.
| ### data.parameters | ||
| __Type:__ Object[] | ||
| __Required:__ No | ||
| __Description:__ A list of parameters passed to the test case execution. |
There was a problem hiding this comment.
to be passed to the test case execution.
| "target": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeee2" | ||
| }, | ||
| { | ||
| "type": "TERC", |
There was a problem hiding this comment.
Should TCS and TCT be allowed to link to TERCC or should it always go via TSS? Just as ED should only be linked from one event I think that the same should hold for TERCC. In the links object doc only TSS is stated as source.
There was a problem hiding this comment.
My bad! No, it shouldn't be there. On a side note, schemas should check link types as well. Will have to do something about that, but first links and meta documentation should be broken down to a per-event level, too. Will create an issue for this.
|
Good point on PREVIOUS_TEST_CASE_EXECUTION. I thought about it myself, but from my experience test case executions are not sequential in nature the way activity executions tend to be. A test case is a (typically) unique combination of IUT, environment and test case version. In that sense, the meaning of "previous" becomes rather obscure, and I'm afraid it would just add more confusion than it would clarity. I could be wrong, though :) |
|
Thanks for the review! I hope you'll find your comments addressed in the latest commit. |
|
Regarding PREVIOUS, I partly agree with you and partly not. A Test activity execution is tied to an IUT in the same way as a test case execution is. And it probably has either a fixed environment to execute the test towards or it has an instantiation of an environment template (or possibly multiple for more complex test activities). So speaking about previous in regards to test activity executions is more or less as obscure as it is for test case executions. But I assume there are other kinds of activities where the previous concept could be suitable. |
|
Exactly, sometimes it may not be relevant for the Activity either, but often it is. Think of e.g. your typical Jenkins build job chewing through new commits one after the other - that is a very sequential structure. Which is why PREVIOUS_ACTIVITY_EXECUTION is an optional link. |
|
I'm fine with this PR. Good job Daniel! |
|
👍 |
d-stahl-ericsson
force-pushed
the
issue120
branch
from
a11bd99
to
4af48a5
Compare
|
👍 |
As per issue #120, introduced two new event types to represent Triggering and Canceling of test case executions, following the same pattern as for Activity event types. The rationale is that the omission of these event types leads to loss of information and the inability to express intent to execute test cases, which in turn leads to the inability to e.g. monitor progress, analyzing queue times and resource scarcity etc. This split also opens up for event based asynchronous communication between test management and test execution.