Submit and vote on feature ideas.

Welcome to the new Parasoft forums! We hope you will enjoy the site and try out some of the new features, like sharing an idea you may have for one of our products or following a category.

Flexible selection of Active DS in DG

dgoedh
dgoedh Posts: 63

Hi,

Currently it is sadly only possible to set an Active DS within a Data Group through using the dropdown selection or a static Environement variable. However during iteration of my test, I want to dynamically set the Active DS e.g. through a runtime variable, e.g. triggered from an overall DS.

Will this be made possible in a future version of Parasoft SOAtest? This will make it more agile and powerful.

Same goes for dynamically selecting the sheet name of an Excel DS.

Thanks in advance.

Daniel

Tagged:

Comments

  • benken_parasoft
    benken_parasoft Posts: 1,228 ✭✭✭

    Currently it is sadly only possible to set an Active DS within a Data Group through using the dropdown selection or a static Environement variable

    For reference, there is also the -dataGroupConfig command line option.

    However during iteration of my test, I want to dynamically set the Active DS e.g. through a runtime variable, e.g. triggered from an overall DS.

    Data sources are initialized with data loaded very early at the start of the execution, prior to any tests being executed. In other words, you can't start having test iterate over a data source then half way through the run reconfigure the data source to use different row data. Perhaps you can clarify or describe a scenario where this makes sense. For example, let's say one data source has 10 rows and another has 50. Are you saying that you want a test to iterate over the first 5 rows from the first then abruptly switch to the second in some way?

  • dgoedh
    dgoedh Posts: 63

    Hi Benken, thanks for the reply. We are not using the CLI yet. We are currently migrating from a framework where validation is done within VB scripts and SOAtest is only used as a driver. It uses a testdata Excel work book with several dedicated sheets from executing aix commands, to pre/post sql inserts/updates, xml/csv validation and last but not least db selects. These are all organized in a single sheet, having a unique runID which VB uses as an identifier. We try to cover all the functionality with native SOAtest test and that is not the problem. It is the organization of the test data. They are just listed in one sheet, underneath eachother and SOAtest can not handle that very well as a datasource iteration. Queries and results are together and the results can have multiple occurences. So, in order to make this work in SOAtest, I made a conversion macro in Excel to seperate all the testcases (e.g. both queries and result values) in a dedicated tab/worksheet and we end up with a huge collection of Excel datasources. I already came up with a 'sequential' solution, to make a master test suite and multiple references (1 per testcase), each having its own datasource which can be selected from the dropdown.
    Currently I am investigating the options for a more iterative approach. Using an aggregate datasource and having the column names set to unique values will still yied in a sequece of DBtool and connected assertions to cater for the db validation.
    As I stated I was hoping for the Data Group to be more flexible, in which I could use a kind of global/switch board Datasource that governs the iterations and in which a runtime variable can set the active Datasource per test case. Currently this can only be done using a 'static' environment variable and will be of no use to me.

    Hopefully I made my (test) case clear. Due to the migration, I am not in the position to alter the queries e.g. in a single outcome, this will require a total overhaul and that is not an option.

    Thanks of investigating. Hope the Data Group will be able to make use of runtime variable real soon.

    Regards,

    Daniel

  • benken_parasoft
    benken_parasoft Posts: 1,228 ✭✭✭
    edited February 2020

    a runtime variable can set the active Datasource per test case

    Thank you for clarifying your request.

    First, if different tests need to use different data then each test needs to use a different data source. The reason being that you can't start having a test iterate over a data source then half way through the run reconfigure the data source to use different row data. As mentioned, Data sources are initialized with data loaded very early at the start of the execution prior to any tests being executed.

    If, for example, you have two tests that need to use different data then you would define two separate data sources. Since you are using Excel, I would just use two Excel data sources. You can configure the active sheet with an environment variable as well. Whether you use two Excel data sources or two Data Group Data sources, the active sheet/group can be controlled with a variable but that variable must be set prior to the tst being executed for the reason I stated earlier

    In the case of a SOAtest environment variable you would define multiple environments, each having a different value for the environment variables you want to use to control what Excel sheet is used. You can specify the active environment prior to running the tst in a number of ways. Some users create different test configurations for each of their environments. So, they run the same tst file with a different test configuration depending on what environment they want to test.

  • dgoedh
    dgoedh Posts: 63

    Hi Benken, Thanks again for your reply. Since I need numerous (20- 100s) different datasources be active per iteration, the environment variable option is not viable (unless it is possible to alter the value of an environment variable along the way ...) So far I have the option open through the REST API, if we have an active license for that feature, to investigate possibilities for switching datasources.
    Otherwise I will have to stick to my current set up of chaining loads of reference tst's in sequence, which can be individually be configured to each use a different datasource. This will get the job done, but it is off course not the most 'sexy' approach.

    Regards,
    Daniel

Tagged