[Test] Derive tests from traces
- show T in the list of tests of C
- if the inputs involved in T are not present in C, ask the user for a mapping
- if the mapping does not map to the same types, fail (maybe propose standard type-to-type mappings like boolean to integer)
#1 Updated by Anonymous almost 4 years ago
should work properly with the constraint mechanism:
if the test in the requirement is changed, the derived test shall be outdated.
Entails that a new constraint shall be introduced between the component and the originating test.
This constraint could then also embed the mapping.
#4 Updated by Anonymous over 2 years ago
- Assignee changed from Anonymous to Anonymous
@Hernan: I don't know where traces are in the current stack of priorities. You can reject if it's low.
But it's otherwise a cool and important (IMO) topic: how to use information from traces to derive more information at the level of the component architecture?
Here I was basically proposing to make use of tests at the requirements level (back then you could add tests to requirements, today we could maybe use an aspect for that, or extend an existing aspect) to automatically get these test for the components traced to this requirement.
Types might mismatch between requirements and components (e.g., you have booleans in requirements but integers in component), therefore one could devise new strategies like automatic or interactive transformation of types.
Anyways if I'm not clear tell me we can discuss it one day. The issue itself can be either kept or rejected, maybe to be replaced by a proper strategy about "how to make use of the information provided by traces in an quasi-automatic manner?"