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.
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.
Hi Radford
thanks for your reply, which i agree with completely.
The main reason i would like to use DataGen is, that the template itself is maintained by our business engineers (with no programming skills), who also run the ReadyAPI tests. They have to change the template sometimes by copy&pasting it from another tool, so these procedure has to be as simple and foolproof as possible.
After the DataGen step, this template is processed by a groovy script step, which is used many times all over the test suite. So theoretically it would be possible to declare the template as multiline String inside the script, but this has some disadvantages:
1.) The business engineers have to carefully copy&past the string into the delimiters to not break the whole groovy script. (if this happens, they usualy won't notice that, so they would wonder why the tests fail.)
2.) This would mix up some data and logic within the groovy script, which is imho the wrong architectural approach. Especially when every other data (properties) is declared in distinct property steps, which will be referenced by the same groovy script.
As we are actually starting to embed this template and groovy script in many existing test suites, i don't feel well with introducing a deprecated feature.
But if you say this feature is deprecated since 2.0 and is still there, i will think about it.
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.
Hi Guys,
Great conversation!
Mithotyn, does it mean that you've found the solution? You will continue using DataGen.
Hi Tanya,
i don't think there is a "solution" at all. Using a deprecated feature should never be the "right solution". But as long as ReadyAPI doesn't provide a suitable replacement for DataGen templates, there simply is NO alternative (in my point of view).
So i am not completly happy, but when DataGen gets never removed from ReadyAPI, i can live with that.
Best regards,
Joachim
