为何Fit/FitNesse？

Question

使用Fit/FitNesse代替xUnit风格的集成测试有什么意义？在我看来，它的语法真的很奇怪而且很不清楚。

真的只是让产品所有者编写测试吗？他们不会！对他们来说太复杂了。那么，为什么还要有Fit/FitNesse？

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

Answer 1

整个过程是与非程序员，通常甚至完全非技术人员，如商业应用程序的前景用户，应用程序应该做什么，然后将其放入测试。虽然进行测试对于他们来说确实太复杂了，但他们应该能够讨论例如填写样本数据的表格。字。最重要的是，与传统规范不同，这些文档与您的应用程序共存，因为自动化测试会强制您更新它们。

请参阅James Shore的Introduction To Fit和Fit Workflow，如果需要，请参考其他文档的链接。

---

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

就像我看到的那样，Fit是一个工具，允许您在文档中记录具有丰富实际示例的业务（如在域中）的用例，最终用户或领域专家（在某些领域）验证和讨论。同时这些例子都是机器可读的，所以它们可以用来驱动自动化测试。你既不是完全由自己写文档，也不是要求它们去做。相反，它是一种协调和讨论的产物，它反映了对双方应用程序将做什么的理解。随着您的进步以及更多角落案例的解决，示例会变得更加丰富。

什么应用程序会做，而不是如何，很重要。这是一种功能规格。因此，它相当广泛，并不是真正由模块组织，而是由使用场景组织。

说出来的例子的测试将在从企业的角度重要方面的测试应用程序的外部行为。是的，你可以称之为商业规则。但让我们看看Diego Jancic的信用评分的例子，只是有一点小小的变化。如果适合文档的一部分是1）列出属性及其得分，然后2）提供客户数据和检查结果，那么这些是实际的业务规则：计分表（属性及其分数）或应用逻辑计算每个客户的分数（根据得分表）？哪些被测试？

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

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

---

一个更普遍的想法，它通常（不总是!!!）更好地编码您的测试中，“业务规则”和公正的东西，某种形式的明确定义的数据是由一些简单的解释，通用的一段代码。然后，以其他方式使用数据变得非常简单：生成文档，迁移到新的测试框架，将应用程序移植到新的环境/编程语言，用于检查是否符合某些外部规则或其他系统（仅使用您的想象力）。从代码中提取这些信息要困难得多，例如。简单的硬编码单元测试或业务规则。

将测试用例存储为数据。由于打算如何使用，因此格式非常具体，但仍然如此。您的域特定测试可能使用不同的格式，如简单的CSV，JSON或YAML（我不是一个XML粉丝，认为）。

---

当我写这个（太长）的更新，我见过article by Gojko Adzic。有趣的是，人们试图在Fit/FitNesse中编程测试，就好像它在IMVHO简单地击败目标的编程语言一样。

Answer 2

这个想法是，你（程序员）定义了一个易于理解的格式，例如Excel工作表。然后，产品所有者输入一些难以理解的信息，这些信息对于那些不在业务中的人是很难理解的......并且您只是验证您的代码在PO期望运行Fit时运行。 在xUnit中使用的方式，可以用于程序员作为易于理解或简单信息的输入。 如果你需要在你的xUnit测试中输入很多奇怪的例子和多个字段，它将变得很难阅读。

想象一下，您必须根据年龄，已婚/单身，子女金额，工资，活动情况决定是否向客户提供贷款...... 作为一名程序员，您无法撰写信息;风险管理者不能编写xUnit测试。

Answer 3

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