在我工作的大多数地方，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正在测试的组件来完成，这样你就可以直接使用它来处理它。蟒蛇。我认为这将使脚本开始变得更容易（因为人们已经知道了语言，并且定义得很好），并且它会减少维护工作 - 增加更多功能的工作量会减少。
然而，由于我从未在实践中看到过这种方法 - 您在这方面的经验是什么？是简单的测试DSL：这是“这里没有发明”的综合症，还是他们通常是最有效的途径？
答案 0 :(得分：0)
最简单的中间步骤可能是使用Python之类的完整编程语言或您建议的其他编程语言生成C ++ / Obj-C测试代码。这将是一个不那么痛苦的步骤，因为您已经在进行代码生成。
答案 1 :(得分：0)
kotlinski背后的想法可能是让测试工程师编写这样的DSL测试用例。在这种情况下，我正在考虑编写一个解释器，将testengineer的代码转换为真正的java / python / ruby代码。