使用FitNesse而不是NUnit

Question

据我了解，有几种情况可能需要使用FitNesse。

• 您希望进行验收测试而非单元测试。
• 您希望将其用作与利益相关者的沟通工具。
• 您希望进行大规模测试，而不是进行粒度测试。
• 您希望非技术人员编写测试。

我的个人观点和经验是：

• 我可以使用NUnit等工具进行验收测试。 Fitnesse基本上只是一个用于在.NET程序集上调用公共方法的框架，可以使用NUnit来完成。
• 利益相关者告诉我他们想要什么。他们很少有兴趣编写Fitnesse测试。他们似乎还有其他/更好/更重要的事情要做。
• 您可以使用FitNesse进行大规模测试。据我所知，您必须将这些大规模测试的所有输入输入到Web浏览器中的纯文本编辑器中。如何从磁盘上的文本文件或excel文件或数据库中读取输入数据更容易？当然，您可以在Web界面中指定磁盘上文件的路径，但是使用NUnit读取同一个文件会带来什么好处呢？
• 这些非技术人员必须在网站上的文本编辑器中按照非常特定的语法编写代码，稍后将调用.NET程序集。 .NET代码变得混乱，因为非技术人员不知道编程，但他仍然指定程序集应该如何工作。

有人可以就此主题分享其他意见吗？ FitNesse对您有何价值？

Answer 1

所以，是的，您可以在nUnit中编写验收测试，但是忽略了这一点。 Fitnesse应该是您的应用程序的另一个UI，表示详细的断言流程：

用户这样做 用户这样做 用户现在看到了这个

理想情况下，健身层能够直接坐在应用程序的最顶层，取代最终的渲染层。

单元测试工具并非真的为此而设计，你能做到吗？当然。但这很奇怪。

在我看来，另一件事是，你有点想做“你想要非技术人员来编写测试”。 Fitnesse是一个合作工具。您应该与利益相关者一起编写测试，给予并获得反馈。然后，它有作为文档的好处。所以一年之后，当有人想知道系统为什么会按照它的方式工作时，你可以提取测试，以BA可以理解的方式显示（与nUnit不同），并说好，如果我们改变它？

Answer 2

FitNesse的设计目的与NUnit完全不同。使用NUnit进行验收测试首先意味着整个测试套件必须用代码编写。 FitNesse的设计目的是，在给定一定程度的准备时，您可以在数据中编写测试。这些是非常不同的操作模式，它们适用于非常不同的资源。他们还鼓励对世界的看法截然不同 - FitNesse测试用例设计师正在假设一个非常简单，直接的转换即将发生，而NUnit用户对转换的工作方式有很多了解并且有钩子进入与转型本身无关的系统。

如果您无法让利益相关者编写用例和功能测试，那么您需要为这些利益相关者提供替代，这是传统QA部门的用武之地。没有利益相关者来做这些事情不是不这样做的借口。

使用FitNesse通过自定义格式读取数据的好处非常简单：它是输入测试用例的标准方法。如果你没有看到这样的好处，也许你需要花一些时间沿着你描述的道路走下去，因为最终你会碰到一些墙，也许它们会帮助你理解。

Answer 3

您问题的典型答案是

“更高级别的测试（例如接受）是很好的，直到你发现问题为止。此时如果你没有单元测试，那么你唯一知道的是某些东西被破坏了 - - 不是特别什么被破坏或者应该在哪里应用修复。“