为什么不使用 Robot Framework？

HitchDev 的创建在某种程度上受到了 robot framework 的启发。

我在 2014 年使用过它，当时它部署在我加入的一个项目中，并在调试测试失败时变得 *非常* 令人沮丧。

下面列出了我讨厌这个框架的原因

1. 调试工具很糟糕

2014 年的最后一根稻草是我试图调试一个测试失败，并发现测试失败的行号和步骤并没有显示给我。

是的，没错，机器人对测试失败的反应不是“嘿，这里有问题”，而是“嘿，有些东西搞砸了，你自己想办法解决吧”。

事实证明，维护人员有 理由 这样做，但这些理由很糟糕。

后来我放弃了它，使用了 Python 自带的单元测试框架，它效果更好，因为它确实 *告诉我* 它失败了。它仍然不是一个适合许多 其他原因 的优秀框架，但至少在这方面，与机器人相比，它是一股清新的空气。

当然，Hitchstory 会告诉你代码失败的确切行号，甚至会给出失败的 Python 代码的堆栈跟踪。我非常小心地避免搞砸这件事。

2. 它不快速失败

快速失败 是软件开发的一般原则，系统会立即在其界面上报告任何可能指示失败的条件。

Robot 不遵循这一原则。

它如何违反这一原则的一个例子是，如果你输入一个未知关键字会发生什么。它会运行

2. DSL 是图灵完备的

DSL 中有一个普遍模式，我称之为“DSL 跑步机”。有人发现一个问题，然后认为“我知道，我会创建一个 DSL 来解决这个问题”。这个 DSL 工作一段时间，创建者很快就会发现一些他们认为应该适应的用例。然后他们添加了一些功能。然后他们看到了其他用例。然后他们添加了更多功能。

然后，在某个时刻，*糟糕*，他们 *无意中* 创建了一种图灵完备的编程语言。这发生在，除其他 DSL 外，C++ 模板、服务器端包含、mediawiki 模板和 sendmail 配置文件 上，所有这些都以其极度难用而闻名。

虽然乍一看，更多功能听起来像是件好事，图灵完备性仅仅是学者感兴趣的一个古怪的副作用，但实际上，无意中创建一个编程语言是一个可怕的、*可怕的* 陷阱。

图灵完备代码本质上难以理解。需要多年的练习才能阅读并理解发生了什么。即使在 *经过* 这些年的练习后，从图灵完备程序中正确地确定行为通常也是不可行的，而这正是... 我们需要测试软件的原因。

Robot 添加的功能使它超越了界限，这些功能包括条件语句、循环和变量。

在这种情况下，拥有 DSL 还有什么意义？Python 是一种 *远* 优越的编程语言。如果你打算编写图灵完备的测试，至少应该用 Python 来写。

此外，高级测试不应使用条件语句和循环来描述行为，而应该将行为描述为一系列声明性的动作。

3. RobotSelenium 与 Robot 紧密耦合

我在最初设计 hitchstory 时也犯了这个错误。使用预先编写的步骤（例如点击）的诱惑力很大。但这不是一个好的方法 - 灵活性太宝贵了。

最后，我发现更好的方法是将步骤方法的内容完全留给开发人员自行决定，并提供与框架无关的库。seleniumdirector 可能被设计为与 hitchstory 配合使用，并且可以用来编写一些 "单行步骤"，比如点击，但该 API 与 hitchstory 之间没有内在的联系，反之亦然。它可以与 py.test 或 unittest *同样* 轻松地配合使用，也可以用来抓取网站。

同样，构成 hitch 框架的所有库都被设计为具有单一的、范围明确的目的（UNIX 哲学），并且完全不受程序员选择如何使用它们的影响。

Robot 做对了什么？

我认为 Robot 做对了一件事 - 它与 gherkin/cucumber 和 hitchstory 共享一个特性 - 它强制在执行代码和故事定义之间进行明确的关注点分离 - 这是一种不同于执行测试的语言。正是这个好想法的核心启发我编写了自己的框架。