Logo etsi

ETSI's Bug Tracker
Main | My View | View Issues | Change Log | Roadmap | Monitor project
  
Notice: information submitted on the ETSI issue Tracker may be incorporated in ETSI publication(s) and therefore subject to the ETSI IPR policy.

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007888Part-1 Metamodel[TDL] New Featurepublic06-12-2019 11:5831-05-2020 15:11
ReporterAndreas Ulrich 
Assigned ToPhilip Makedonski 
PrioritynormalSeverityfeatureReproducibilityhave not tried
StatusresolvedResolutionno change required 
PlatformOSOS Version
Product Version[TDL] Part-1 V1.4.1 
Target VersionFixed in Version 
Summary0007888: Test data specification for parameterised test descriptions
DescriptionWhen considering parameterised test descriptions at top level (i.e. TDs that are not called from any other TD), there is a need to specify parameter values to make them executable operationally.

The issue is related to keyword-driven testing, which technologies that are competitive to TDL deploy, e.g. Cucumber, SpecFlow, Robot Framework. Their approach is usually to specify data tables that are read at runtime to feed the data into tests for execution.

A similar approach shall be investigated for TDL.
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0015610)
Finn Kristoffersen (developer)
31-01-2020 08:16

 For TDL the solution is to specify a top level test description that sequentially invokes the parameterised test description over a collection
of data parameters.
Hence there is no need for change to TDL-MM. However, an annex with an example
illustrating specifying this type of testing may be included.
(0015612)
Philip Makedonski (manager)
31-01-2020 15:26

 Some more background:

A data type embedding the parameters for a test description can be used to encapsulate the relevant combinations of parameters into a collection. A test description can take that collection as input and invoke the original test description in a bounded loop iterating over the elements of the collection which are in turn parameter combinations. After evaluating the implications, even a shortcut construct will not provide substantial benefit as the data type integrating the input parameters still needs to be defined, along with at least one instances (or inline instances) defining the combinations, along with a collection type, along with a collection instance aggregating the individual combinations.

The overhead and complexity is substantial and will need to be repeated for every test description with different input parameters. If such collections are reused frequently then it perhaps makes some sense. A more specific use case is necessary to justify the effort for the realisation of this feature. For the time being, using test description references with parameters covers the basic use case. Different data mappings can provide further flexibility.
(0015660)
Philip Makedonski (manager)
31-05-2020 15:11

 Related examples added in TR 103 119 to illustrate how the use case can be addressed with existing facilities.

- Issue History
Date Modified Username Field Change
06-12-2019 11:58 Andreas Ulrich New Issue
06-12-2019 11:58 Andreas Ulrich Status new => assigned
06-12-2019 11:58 Andreas Ulrich Assigned To => Philip Makedonski
31-01-2020 08:16 Finn Kristoffersen Note Added: 0015610
31-01-2020 08:16 Finn Kristoffersen Resolution open => no change required
31-01-2020 15:26 Philip Makedonski Note Added: 0015612
31-05-2020 15:11 Philip Makedonski Note Added: 0015660
31-05-2020 15:11 Philip Makedonski Status assigned => resolved

MantisBT 1.2.14 [^]
Copyright © 2000 - 2024 MantisBT Team
Powered by Mantis Bugtracker