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 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.
