使用 FitNesse 而不是 NUnit
据我了解，在某些情况下您可能需要使用 FitNesse。
- 您想要进行验收测试而不是单元测试。
- 您想将其用作与利益相关者的沟通工具。
- 您想要进行大规模测试而不是细粒度测试。
- 您希望非技术人员来编写测试。
我个人的观点和经验是：
- 我可以使用NUnit等工具进行验收测试。 Fitnesse 基本上只是一个用于在 .NET 程序集上调用公共方法的框架，这可以使用 NUnit 来完成。
- 利益相关者告诉我他们想要什么。他们很少对编写 Fitnesse 测试感兴趣。他们似乎还有其他/更好/更重要的事情要做。
- 您可以使用 FitNesse 进行大规模测试。据我所知，您必须将这些大规模测试的所有输入输入到网络浏览器中的纯文本编辑器中。这比从磁盘上的文本文件、Excel 文件或数据库读取输入数据更容易吗？当然，您可以在 Web 界面中指定磁盘上文件的路径，但是与使用 NUnit 读取同一文件相比，这有什么好处呢？
- 这些非技术人员必须在网站上的文本编辑器中按照非常特定的语法编写代码，稍后将调用 .NET 程序集。 .NET 代码变得混乱，因为非技术人员不懂编程，但他仍在指定程序集应如何工作。
有人可以就这个主题分享一些其他意见吗？ FitNesse 对您有何价值？
As I've understood it, there's a couple of cases when you may want to use FitNesse.
- You want to do acceptance testing rather than unit testing.
- You want to use it as a communication tool with the stake holder.
- You want to do large scale tests rather than granular tests.
- You want non-technical people to write the tests.
My personal opinion and experience is:
- I can do acceptance testing using tools such as NUnit. Fitnesse is basically just a framework for calling public methods on a .NET assembly, which can be done using NUnit to.
- The stakeholders tell me what they want. They are rarely interested in writing Fitnesse tests. They seem to have other/better/more important things to do.
- You could do large scale tests using FitNesse. As far as I know, you would have to enter all input for these large scale tests into a plain text editor in a web browser. How would this be easier than reading the input data from a text file on disk, or an excel file or a database? Sure, you could specify the path to the file on disk in the web interface, but what benefit would this give over using NUnit to read that same file?
- These non-technical people have to write code following a very specific syntax in a text editor on a web site, which will call .NET assemblies later on. The .NET code gets messy, since the non-technical person doesn't know programming but he's still specifying how the assembly should work.
Can someone share some other opinions on the subject? How have FitNesse been valuable to you?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
所以，是的，您可以在 nUnit 中编写验收测试，但这没有抓住重点。 Fitnesse 应该是应用程序的替代 UI，它表达了详细的断言流程：
用户执行此操作
用户这样做
用户现在看到了这
一点 理想情况下，健身层能够直接位于应用程序的最顶层，取代最终的渲染层。
单元测试工具并不是专门为此设计的，你能做到吗？当然。但这很奇怪。
另一件事，在我看来，你的想法有点偏离“你希望非技术人员来编写测试”。 Fitnesse 是一种协作工具。您应该与利益相关者一起编写测试，提供并获得反馈。然后，它的好处是作为文档。所以一年后，当有人想知道为什么系统会这样工作时，你可以调出测试，以 BA 可以理解的方式显示（与 nUnit 不同），然后说，好吧，就是这样，我们应该改变它吗？ ？
So yes, you could write acceptance tests in nUnit, but that misses the point. Fitnesse is supposed to be an alternative UI to your application that expresses a detailed flow of assertions:
The user does this
The user does that
the user now sees this
Ideally the fitness layer is capable of sitting directly over the very top level of your application replacing the final rendering layer.
Unit testing tools are not really designed for that, can you do it? Sure. But it's weird.
Another thing, in my opinion, is that you're a bit off in the idea that "You want non-technical people to write the tests". Fitnesse is a tool for collaboration. You should be writing the tests WITH the stakeholders, giving and getting feedback. Then, it has the benefit of being the documentation. So a year later, when someone wants to know why the system works the way it does, you can pull up the tests, displayed in a way a BA can understand (unlike nUnit) and say well, here it is, should we change it?
FitNesse 的设计目的与 NUnit 完全不同。使用 NUnit 进行验收测试首先意味着整个测试套件必须用代码编写。 FitNesse 的设计目的是让您在进行一定程度的准备后，可以在数据中编写测试。这些是非常不同的操作模式，并且它们适用于非常不同的资源。他们还鼓励对世界有截然不同的看法——FitNesse 测试用例设计者假设将会发生一个非常简单、直接的转换，而 NUnit 用户对转换如何工作有大量的知识，并且有钩子与转变本身无关的系统。
如果您无法让利益相关者编写用例和功能测试，那么您需要为这些利益相关者找一个替身，这就是传统的 QA 部门的用武之地。没有利益相关者来做这些事情并不是做这些事情的借口。不做。
使用 FitNesse 通过自定义格式读取数据的好处非常简单：这是输入测试用例的标准方法。如果您没有看到其中的好处，也许您需要花一些时间沿着您描述的路径走下去，因为最终您会遇到一些困难，也许它们会帮助您理解。
FitNesse is designed for a wholly different purpose than NUnit. Doing acceptance testing with NUnit means, first of all, that the entire test suite has to be written in code. FitNesse is designed with the intent that you can, given a certain level of preparation, write your tests in data. These are very different modes of operation, and they apply to very different resources. They also encourage very different views of the world - a FitNesse test case designer is working on the assumption that a very simple, straightforward transformation is going to happen, whereas an NUnit user has a great deal of knowledge about how that transformation works and has hooks into the system which have nothing to do with the transformation itself.
If you can't get stakeholders to write use cases and functional tests, then you need a stand-in for those stakeholders, which is where a traditional QA department comes in. Not having a stakeholder to do this stuff isn't an excuse for not doing it.
The benefit of using FitNesse to read your data over a custom format is pretty simple: It's a standard way to enter test cases. If you don't see the benefit in that, perhaps you need to spend some time going down the path you describe, because eventually you're going to hit some walls and maybe they'll help you understand.
您的问题的典型答案是
“在您发现问题之前，更高级别的测试（例如验收）非常好。此时，如果您没有单元测试，那么您唯一知道的就是某件事 已损坏 - 不是具体什么被损坏或应在何处应用修复。”
The typical answer for your question is
"Higher level tests (such as acceptance) are great until you find the problem. At that point if you don't have unit tests then the only thing you know is that something is broken--not specifically what is broken or where the fix should be applied."