Add framework for structuring expected results for Example Models #17
Conversation
Entenwilli
force-pushed
the
integration-testing-framework
branch
from
22e1cd5 to
12b7df6
Compare
Entenwilli
force-pushed
the
integration-testing-framework
branch
from
12b7df6 to
59db7d6
Compare
|
@sebinside @Nicolas-Boltz For the next meeting: |
|
Rename casestudies to scenarios. Move everything with constraints in scenarios folder |
…els or scenarios)
Entenwilli
force-pushed
the
integration-testing-framework
branch
from
68a9751 to
7342f7c
Compare
Entenwilli
requested review from
uuqjz,
Nicolas-Boltz and
sebinside
and removed request for
uuqjz
| private final List<ExpectedCharacteristic> vertexCharacteristics; | ||
| private final Map<String, List<ExpectedCharacteristic>> dataCharacteristics; | ||
|
|
||
| public ExpectedViolation(int flowGraphIndex, Identifier identifier, List<ExpectedCharacteristic> vertexCharacteristics, |
There was a problem hiding this comment.
General comment: Is there a need to use an identifier? Could you not use a vertex instead? I do not like having hard coded ids here, as they might not be applicable for models that are dynamically generated, derived or whatever.
Nothing to necessarily change, but to disucss.
There was a problem hiding this comment.
Just to consider, and document, why this is currently the case:
We cannot just use the vertex here, because we only know the IDs of the violating elements and whether it is calling or returning (only applicable to PCM).
What we could do, however, is allowing Identifiers to be constructed from vertices
Note
This PR is still is done. Please review it with the
unit-testingbranch in DataFlowAnalysis/DataFlowAnalysis#260This PR introduces a framework for structuring the expected results from the Example Models contained in this repository.
For each model, expected violations are contained in the
srcof the models bundle.Additionally, this PR adds several new Example Models from older work (see: https://doi.org/10.1016/j.jss.2021.111138)