You're making the same exact mistake that the guy who decided ant should use xml as a programming language did.
As soon as you need loops, conditionals, subroutines -- which are all very common when writing tests -- you're making up your own language with horrible warts.
>You're making the same exact mistake that the guy who decided ant should use xml as a programming language did.
Ant was a badly done turing complete langauge. I did not create a turing complete language I created an very, very dumb declarative language with no functions or control structures - only data.
>As soon as you need loops, conditionals, subroutines -- which are all very common when writing tests
I already have loops and conditionals via jinja2 (a templating language I did not create) on the high level and in python on the step level.
I am not and will never implementing any control structures in YAML (a la ant). The YAML will always remain dumb to help maintain a strict separation of concerns and test readability.
>you're making up your own language with horrible warts.
Down this path lies madness. Now the user has to deal with the difference between YAML values and Jinja values. Can't really reference YAML data set in other files, or other places in this file.
It's a tangled mess. Please don't do this to your users.
Maybe use tcl? Guile? Some real language that lends itself to making a clean api/dsl for what you're trying to do.
I agree that YAML block style as on lines 22, 23, 24 should be eliminated (I will probably prevent my framework from parsing this). If you use an unescaped { or } it should signify that you are using Jinja2.
Similarly, I'm no fan of the {% sets %} at the top - it's a code smell.
Apart from those things, though, what you linked to seems easy to read and understand to me.
I'm absolutely positive that Tcl or Guile (or python) would create the potential for bigger messes than what you just linked to under similar circumstances. Simply being turing complete is enough for that.
The templating language isn't and can't be used to define test control flow.
It's only used to generate test cases - e.g. 7 login scenario tests on 7 different browsers. Or, as on my website, two virtually identical tests running on two different versions of python.
It isn't necessary to write test cases using jinja2 either. YAML on its own is enough.
As soon as you need loops, conditionals, subroutines -- which are all very common when writing tests -- you're making up your own language with horrible warts.