Skip to content
Snippets Groups Projects
Commit 0120d6eb authored by Philip Makedonski's avatar Philip Makedonski
Browse files

+ updated examples

parent e909dc27
No related branches found
No related tags found
No related merge requests found
......@@ -7,11 +7,54 @@ Package Descriptions {
Import all from HTTP.MessageBased
Annotation Failure
Type ^PICS extends Boolean
^PICS MW_8040
^PICS MW_8345
PICS xxx
//introduce dedicated type that extends boolean?
// Type ^PICS extends Boolean
// PICS MW_8040
// PICS MW_8345
//or just annotated booleans? (probably more consistent):
@PICS Boolean MW_8040
@PICS Boolean MW_8345
//TODO: add constraints for PICS guards?
//TODO: make PICS a sub-type of simple data instance?
Use "settings" as settings
Map MW_8040 to "pics.mw_8040" in settings as MW_8040_MAPPING
Map MW_8345 to "pics.mw_8345" in settings as MW_8345_MAPPING
Boolean TD_SSP_01_Completed
PICS MW_8345x
Test Purpose tpName {
Objective: "description"
Reference: "reference"
PICS: MW_8345x and MW_8345x
}
//import
//@PICSs [ (MW_8040 or MW_8345) ] for testDescriptionName
Test Description testDescriptionName
uses TestLanArchitecture
// if [ (MW_8040 or MW_8345) ] {
// pm::mpi sends rGET() to X::mpi
//
// }
//TODO: annotation of behaviour or of block? (block in TPD)
//-> syntactically not possible to annotate block at the moment
//-> even with exception, still assigned to behaviour
//-> moved inside guard
// @PICS
[ @PICS (MW_8040 or MW_8345) ] //if not true -> verdict N/A? test not executed
{
@Initial conditions {
//-> aka preamble (postamble for final conditions)
//if unexpected -> verdict inconclusive, map to junit annotations
pm::mpi sends rGET() to X::mpi
}
//...
}
String modules_state_uri
Use "pm.settings.json" as SETTINGS
......@@ -57,7 +100,12 @@ Package Descriptions {
Objective: TD_MDD_01
Configuration: TestLanArchitecture //TREE_CFG?
PICS: (MW_8040 or MW_8345) //etc.
Initial conditions
//TODO: add annotation to guard/expression to distinguish from regular guards?
//->turn PICS keyword into a annotation?
Initial conditions
//TODO: do we need different semantics for unexpected behaviour within initial/final conditions?
//e.g. inconclusive instead of fail?
//->in case describe in part 4/1
with {
//initial textual
perform action: "Postman has been correctly initialized earlier, by executing
......
......@@ -28,13 +28,14 @@ Package Standard {
Annotation Master
Annotation MappingName
//standard annotations for STO
Annotation Initial conditions
Annotation Expected behaviour
Annotation Final conditions
Annotation Test Purpose Description
Annotation when
Annotation then
//standard annotations for STO
Annotation Initial conditions
Annotation Expected behaviour
Annotation Final conditions
Annotation Test Purpose Description
Annotation when
Annotation then
Annotation PICS
Predefined == returns Boolean
Predefined != returns Boolean
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment