Domain specific languages for automated testing, good idea?

in most places I worked at, automated testing of C++/Obj-C components has been done using simplistic domain specific languages implemented directly in the component.

Just so that you get the idea, test scripts can look roughly like this:

do_this
do_that
repeat 10
do_more_stuff_with_args 5 3
again

...and the DSL would translate those commands to something more or less complicated (usually resulting in a call to one or several C++/Obj-C functions).

My first idea when seeing something like this, is that it would be nicer working in some established, well-defined language rather than a homegrown DSL. For example, this could be done by embedding Scheme or Lua to get the basics for free, or by Swigging the component being tested so you can work with it directly from e.g. Python. I am thinking it would make it easier to get started scripting (since people already may known the language, and it's well defined), and that it would reduce maintenance work - there would be less work to add more functionality.

However, since I have never seen this approach taken in practice - what is your开发者_C百科 experience in this matter? Are simplistic testing DSL:s a case of "not invented here" syndrome, or are they usually the most effective road to take?

The easiest intermediate step would probably be to generate the C++/Obj-C testing code with a full programming language like Python or one of the other ones you suggested. This would be a less painful step because you are already doing code generation.

The idea behind kotlinski, could be to make test engineers to write such DSL test cases. In which case, I am thinking about writing an interpreter to convert the testengineer's code into a real java/python/ruby code.