当测试技术含量很高时，为什么要使用 FitNesse？
在我看来 FitNesse 具有以下优点：
让非技术人员定义测试数据集和预期数据结果（他们如何定义成功）。 技术人员可以是用户、产品经理，也可能是无法访问源代码和/或不知道如何用源语言进行编程的软件质量专业人员。
让非技术人员运行测试并快速了解被测代码的运行状况。
我正在使用一个代码库，其中“用户界面”是库中的 API，因此只有了解该语言并可以直接访问该 API 的其他技术专业人员才可以理解和相关。我需要选择一种执行集成测试的方法。我对 FitNesse 很感兴趣，但我不明白为什么我会这么麻烦。这些优点在这种情况下仍然适用：
它强制执行定义测试的标准样式，因此需要使用相同代码的其他软件专业人员很容易理解它们。
它可以让源代码的作者和维护者快速查看测试在哪里失败以及如何失败。
测试是用与源代码相同的语言编写的，因此不需要单独的专业知识体系（即perl或python）。
但是，还有其他简单的方法可以实现相同的目标，而无需离开代码编辑器。另外，为了运行测试，我没有找到将 FitNesse 测试绑定到自动化系统中的方法，例如让持续集成服务器使用新版本运行它们。我也不知道如何在开发平台以外的硬件平台上运行 FitNesse 测试，因此它们不会捕获计时问题。
那么，如果您在“用户”与您一样具有技术水平的环境中使用 FitNesse，为什么呢？如果您尝试过并决定不这样做，您的理由是什么？
如果您使用 FitNesse 测试用于单独专有硬件（嵌入式系统）的代码，那么它是如何工作的？
It seems to me FitNesse has the following advantages:
Let a non-technical person define sets of test data and expected results (how they define success). A non-technical person could be a user, a product manager, or possibly a software quality professional who does not have access to the source code and/or does not know how to program in the source language.
Lets the non-technical person run the tests and quickly get a sense of the health of the code under test.
I'm working with a code base where the "user interface" is an API in a library, so it is understandable and relevant only to other technical professionals who know the language and have direct access to the API. I need to choose a way to perform integration tests. I'm intrigued by FitNesse but I don't understand why I might bother. These are advantages that still apply in this case:
It enforces a standard style for defining tests, so they're easy to understand by other software professionals who need to work with the same code.
It lets the source code's author and maintainers quickly see where a test fails and how it failed.
Tests are written in the same language as the source code so a separate body of expertise is not needed (i.e. perl or python).
However, there are other simple ways to achieve those same goals, without having to leave your code editor. Also, in order to run the tests, I don't see a way to tie FitNesse tests into an automated system, such as having a continuous integration server run them with new builds. I also don't see how to run FitNesse tests on a hardware platform other than the development platform, so they would not catch timing issues.
So, if you use FitNesse in an environment where your "user" is just as technical as you are, why? If you tried it out and decided against it, what were your reasons?
If you use FitNesse to test code meant for separate proprietary hardware (an embedded system), how does that work?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我完全同意您的主张，即难以融入自动化构建系统是一个严重的缺陷（将上面的评论扩展到答案），因此我选择使用 Fit for C++ 的替代实现 CeeFit。托管 CeeFit 文档的原始网站 (ceefit.woldrich.com) 已关闭好几个月了，但现在似乎又恢复了。 CeeFit 可以轻松实现自动化并集成到任何 CI 中，但缺乏 CruiseControl.NET 可接受的任何格式的输出，例如至于 CeeFit 是否可以在嵌入式系统上工作，不确定，文档中没有提及。
I completely agree with your assertion, that being difficult to incorporate into the automated build system is a serious flaw (extending the comment above to an answer) and for that reason I chose to go with an alternative implementation of Fit for C++, CeeFit. The original website (ceefit.woldrich.com) that hosted the documentation on CeeFit was down for many months, but seems to be back up now. CeeFit can be easily automated and integrated into any CI, but there is a lack of output in any format acceptable by CruiseControl.NET for e.g. As for whether CeeFit can work on embedded systems not sure, the documentation doesn't mention any.