用于自动化测试的领域特定语言，好主意吗？
在我工作过的大多数地方，C++/Obj-C 组件的自动化测试都是使用直接在组件中实现的简单的领域特定语言来完成的。
为了让您明白这一点，测试脚本可以大致如下所示：
do_this
do_that
repeat 10
do_more_stuff_with_args 5 3
again
...DSL 会将这些命令转换为或多或少复杂的命令（通常会导致调用一个或多个 C++/Obj-C 函数）。
当看到这样的东西时，我的第一个想法是，使用某种成熟的、定义良好的语言而不是本地开发的 DSL 会更好。例如，这可以通过嵌入Scheme或Lua来免费获得基础知识来完成，或者通过Swigging正在测试的组件来完成，这样您就可以直接从Python等中使用它。我认为这将使开始编写脚本变得更容易（因为人们可能已经知道这种语言，并且它的定义很好），并且它会减少维护工作 - 添加更多功能的工作会更少。
然而，由于我从未见过这种方法在实践中被采用——您在这方面的经验是什么？简单化的 DSL 测试是“不是这里发明的”综合症的一个例子，还是它们通常是最有效的方法？
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 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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
最简单的中间步骤可能是使用完整的编程语言（例如 Python 或您建议的其他语言之一）生成 C++/Obj-C 测试代码。这将是一个不那么痛苦的步骤，因为您已经在进行代码生成了。
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.
kotlinski 背后的想法可能是让测试工程师编写此类 DSL 测试用例。在这种情况下，我正在考虑编写一个解释器来将测试工程师的代码转换为真正的 java/python/ruby 代码。
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.