Forum Discussion

Mithotyn's avatar
Mithotyn
Occasional Contributor
6 years ago
Solved

DataGen deprecated - Alternatives to define templates/multiline properties?

Hi all,

 

in our project (using ReadyAPI 2.6.0) we do need the possibility to define one multiline template per step with property expansion enabled. DataGen templates do have exactly the expected behaviour, but unfortunately the docu states that DataGen is deprecated and will be removed in the next releases.

 

The docu also states, that DataSource should be the proper replacement, but it isn't by far. There is no way to define some multiline text and i don't need the feature of multiple rows.

"DataSource" is surely the proper way to define database like sets of entries with rows/columns to iterate over, but not to define a single static template.

 

So what are my options?

 

Why is DataGen deprecated? When will it be removed? Why isn't it possible to define simple multiline properties? What else could i do to achive this goal?

 

Best regards,
Joachim

  • Ahh.... just read the release notes for version 2.1.

     


    the DataGen step will remain in the product, but will not evolve.

    With this, i think it is safe to use DataGen for templating purpose.

12 Replies

  • richie's avatar
    richie
    Community Hero

    Hi,

     

    I don't know anything about this at all other than what I read maybe 18 months ago and a couple of quick tests around the same time.

     

    It did say that the Data Gen step was being deprecated and to the use the 'Data Generator' Datasource option - I only had a quick play with it - but it seemed to be easier to use than the Data Gen step.

     

    Also - I'd be surprised if SmartBear deprecated one step to replace it by embedding the equivalent functionality in another step if it restricted the functionality to a point that is lesser than the current Data Gen functionality.

     

    I don't mean to be rude - but are you sure the Datagenerator Datasource option does NOT give you what you need?

     

    Thanks,

     

    richie

    • Mithotyn's avatar
      Mithotyn
      Occasional Contributor

      Hi richie,

       

      no i am not sure, that's the reason why i was asking the community. :-)

       

      With DataGen, there is explicitly the possibility to create Templates:

       


      A template property lets you create complex multi-line values. It is useful when you generate a request body.

      Tip: A template can also contain property expansions. So you can use other properties of the test step.

      After beeing deprecated, the docu recommends the following replacement:

       


      Template DataGen does not have a direct alternative. If you need to simulate it in your tests, generate the values with the DataSource test step and add them to the request by using property expansions.


      Within the DataSource, i can use Generators to generate different type of pre defined values (Address, Phone Number, GUID, ...) and "Custom Strings". But these are only single line strings, as DataSource generally is intended to act like a database which generates rows of data.

       

      The "Properties" test step could be a suitable replacement, as it defines static key/value pairs. But unfortunately, the values are also only single line and there is no property expansion within the values.

       

      So with DataGen beeing deprecated, i can't find any posibility to define a single multiline (template like) property to be passed to my test step.

       

      Regards, Joachim

      • Radford's avatar
        Radford
        Super Contributor

        Mithotyn, Firstly do I agree with you that I don't feel the DataSource test is an inferior replacement. My main issue is that the DataGen test step is so simple to use. By the sounds of it we make similar use of it to generate complex data that can be simply referenced as a property, where we are different is I almost exclusively use the Groovy script option.

         

        I will usually group together a collection of related but independent properties into a single DataGen step. With the Groovy Data Source (as recommended by the documentation) you only have a single script for all the properties you define. Thus you end up with a single script that has to generate all the properties (I feel this just makes things confusing and harder to maintain), or you have multiple Groovy Data Source each with one property (bloating your test case).

         

        The Data Source test step seems to work very well for looping sets of data (I have in fact used the Groovy Data Source very successfully for looping through data), but not when you want specific data values, e.g. scenario specific data. It feels like the Data Source test step is a suitable replacement for the DataGen list, or DataGen number (using a Data Generator source). But then the DataGen Script and DataGen Template were shoe-horned in. I'll just repeat that I think the DataGen test step is simpler to use and maintain.

         

        I don't think the DataGen test step is going anywhere soon, while it was deprecated in version 2.0 it was actually enhanced in version 2.1 I also would really hope that if it actually was going to be removed then we would get advance notice of it's specific removal, not just have it disappear in a new version! Rightly or wrongly I'm still using them.

         

        All that being said Mithotyn if you really don't want to use the DataGen step, have you considered using a Groovy Data Source with triple quoted strings?  Here is another good page where it has a detailed example of templating with them.

  • Radford's avatar
    Radford
    Super Contributor

    Hi Mithotyn, you wrote in your original post that.

     

    "but unfortunately the docu states that DataGen is deprecated and will be removed in the next releases."

     

    Could you post a link to this? We make use of the DataGen step and need to know if it's going to be actually removed (as opposed to just being deprecated). I had a look but couldn't find it.

     

    Thanks.