fitnesse - 为什么适合/FitNesse？

Question

使用 Fit/FitNesse 而不是 xUnit 样式的集成测试有什么意义？在我看来，它的语法非常奇怪且非常不清楚。

真的只是让产品负责人写测试吗？他们不会！这对他们来说太复杂了。那么，为什么任何人都应该适合/FitNesse？

更新所以它完全适合业务规则测试吗？

Answer 1

重点是与非程序员，甚至是像业务应用程序的潜在用户这样的完全非技术人员一起工作，确定应用程序应该做什么，然后将其投入测试。虽然让测试工作对他们来说确实太复杂了，但他们应该能够讨论用 Word 等填写的示例数据表。最棒的是，与传统规范不同，这些文档与您的应用程序一起存在，因为自动化测试会迫使您更新它们。

请参阅James Shore 的“拟合和拟合工作流程简介”，如果需要，可以点击指向其余文档的链接。

---

更新：取决于您所说的业务规则是什么意思？;-) 有些人会非常狭隘地理解它（例如在业务规则引擎等中），而其他人则非常广泛。

在我看来，Fit 是一个工具，它允许您在文档中用丰富的实际示例写下业务（如在领域中）用例，最终用户或领域专家（在某些领域中）可以理解、验证和讨论这些用例。同时这些示例是机器可读的形式，因此它们可以用于驱动自动化测试，您既不需要完全自己编写文档，也不需要他们这样做。相反，它是调用和讨论的产物，反映了双方对应用程序将要做什么的理解不断加深。随着您的进步和解决更多极端案例，示例会变得越来越丰富。

重要的是应用程序将做什么，而不是如何。这是功能规范的一种形式。因此，它相当广泛，并没有真正按模块组织，而是按使用场景组织。

来自示例的测试将在从业务角度来看重要的方面测试应用程序的外部行为。是的，你可以称之为业务规则。但是，让我们看看 Diego Jancic 的信用评分示例，只是有点扭曲。如果fit文档的一部分是1）列出属性及其分数，然后2）提供客户数据和检查结果，那么实际的业务规则是什么：评分表（属性及其分数）或应用程序逻辑计算每个客户的分数（基于评分表）？哪些经过测试？

Fit/FitNesse 测试似乎更适合验收测试。其他测试（当您不关心与客户、用户、领域专家等的合作时，您只想自动化测试）可能会更容易以更传统的方式编写和维护。xUnit 非常适合单元测试和 api 测试。每个 Web 框架都应该在其修改-构建-测试-部署周期中集成一些用于 Web 应用程序/服务测试的工具，例如。django 有它的小测试客户端。你有很多选择。

而且您总是可以编写自己的工具（或者最好调整一些现有的工具）以更好地适应（双关语）您感兴趣的特定领域的一些测试。

---

一个更普遍的想法。将测试、“业务规则”和几乎任何东西编码为某种形式的定义良好的数据，这些数据由一些简单的通用代码片段解释，通常（并不总是！！！）更好。然后很容易以其他方式使用数据：生成文档，迁移到新的测试框架，将应用程序移植到新的环境/编程语言，用于检查与某些外部规则或其他系统的一致性（请发挥您的想象力）。从代码中提取这些信息要困难得多，例如。简单的硬编码单元测试或业务规则。

Fit 将测试用例存储为数据。由于它的使用方式，采用非常具体的格式，但仍然如此。您的特定领域测试可能使用不同的格式，例如简单的 CSV、JSON 或 YAML。

Answer 2

这个想法是您（程序员）定义一个易于理解的格式，例如 Excel 表。然后，产品负责人输入的信息对于非业务人员来说难以理解......您只需验证您的代码是否按照 PO 预期运行 Fit 的方式工作。xUnit中使用的方式，可以供程序员作为输入方便理解或简单的信息。如果你需要在你的 xUnit 测试中输入很多带有多个字段的奇怪示例，那么它会变得难以阅读。

想象一个案例，您必须根据年龄、已婚/单身、子女数量、工资、活动等来决定是否向客户提供贷款……作为程序员，您无法编写该信息；并且风险经理不能编写 xUnit 测试。

Answer 3

有助于减少回归和错误测试中的冗余。构建可管理的测试用例存储库。它就像一次构建并永远使用。

Answer 4

这在 QA 和开发团队的合作中非常有用：QA 可以向开发人员显示失败的测试结果，开发人员将轻松帮助解决环境问题，并了解重现错误的步骤。它适用于 UI 甚至 API 测试。