为什么使用 hitchstory 而不是单元测试框架？

注意：此论点仍在完善中，还需要修改/添加一些内容。

这不是反对以下内容的论点

这些在正确的上下文中都是好事。这纯粹是关于 xUnit 框架的测试方法 - py.test、nose、unittest2、jUnit 等，无论它们是用来编写传统的“单元测试”、集成测试还是端到端测试。

总的来说，代码有两种类型 - 算法代码和集成代码。以下是前者的几个例子

以下是后者的几个例子

低级算法代码测试的不适用性

低级算法代码测试看起来有点像 py.test 主页中的这个测试“递增器”的示例

def test_answer():
    assert inc(3) == 4

这实际上是一个清晰测试的良好示例。意图很明显，标签很描述性。

这之所以有效，是因为代码尽管是图灵完备的，但却是声明性和简单的。然而，问题会随着时间的推移而增大，

不存在关注点分离问题，尽管使用了图灵完备的语言，但代码并没有“过于强大”而妨碍理解。

然而，

最终归结为两个编程原则，hitchstory 提供了“导轨”来引导你

Hitchstory 故事描述了一系列事件，这些事件描述了用户或用户系统与你的代码的交互。这可以用来描述任何软件系统的功能。**不必**使用图灵完备的代码来描述一系列事件，因此，根据最小权力原则，你不应该使用图灵完备的代码来做到这一点。

然而，图灵完备的代码*是*必需的，用于设置和模拟这组事件。这就是 hitchstory 引擎的用途，它必须用图灵完备的 Python 编写。

故事定义和故事执行之间的这种划分也为关注点分离创建了一个自然的屏障。故事定义放在故事中，而执行放在引擎中。单元测试框架没有这种自然屏障来分离关注点。

Web 开发人员可能熟悉这个原则，因为它体现在 Web 开发框架中，其中（故意较不强大的）模板语言用于呈现 HTML，并与功能更强大的“控制器”（或在 Django 中称为“视图”）代码之间划分为界。

单元测试框架中无法（也不可能）复制的其他功能

hitchdev 框架确实附带了许多有用的测试工具，如果你愿意，也可以轻松地将它们与 py.test 一起使用。