The difference between NUnit/MbUnit and FitNesse is that NUnit/MbUnit are intended to be used for unit tests, while FitNesse is for acceptance tests.
Unit tests test a single, small unit of code, such as a method, to ensure that it executes as the programmer intended. For example, you might use a unit test to ensure that a factorial-computing method returns the correct results for a set of numbers, including some edge cases.
Acceptance tests are intended to test whether a high-level design requirement is met. As an example, if you were writing a Pac-Man clone, and one of the requirements was "A new level begins when the last dot of the previous level is eaten," an acceptance test would test to see whether that requirement as a whole is satisfied by the code--not the specific pieces of code that consume a dot, check ending conditions, and load new levels (although that code would be exercised in the process of running the acceptance test). Acceptance tests typically are written without regard to the specific implementation of the requirement.
A lot of QA departments execute long lists of acceptance tests by hand, which can be very time consuming. Fit and FitNesse are tools that assist in automating acceptance tests, which can save a lot of time.
The last company I worked with used FitNesse with some degree of success. Its not meant to be used in the same way as NUnit, in which the degree of testing is very granular. FitNesse is used more for "acceptance testing", involving less granular, "large scale" tests. To compare the two, lets say we were writing an app for processing checks at a bank:
If we're writing unit tests with NUnit, we'd test each individual method of our Check objects, Transaction objects, TransactionProcessor factories, test each method of our Data Access Layer, etc. You're tests are very close to the source code.
If we're writing acceptance tests, we might set up a days worth of transactions, prompt the app to process the transaction, and make sure that the code produces the correct invoice statements and reports. You're at a much higher level than unit tests, usually at a vantage point where you can test all the applications business rules at once.
Unit tests tell programmers whether the code contains any defects, and acceptance tests tell business analysts that the applications meets user expectations.
FitNesse test cases are designed to be written by people without technical knowledge. You still need programmers to write the DLLs to expose the innards of the application to FitNesse, but otherwise the use cases are supposed to be written by non-technical people who don't know anything about the source code (i.e. business analysts and QA).
My company used FitNesse to test one of our "core" applications, which happened to be written over the course of 20 years using a dead COBOL-like language. The core app did not have unit tests, and it was nearly impossible to create a unit testing framework in the original language. Forturnately, the language had COM bindings which exposed a few public methods to .NET and Java, allowing us to write automated test cases for this application for the first time in 20 years. It wasn't pretty, but the business people liked it.
FitNesse is basically a wiki which stores all the test cases. Most probably for acceptance testing. In Test first development the test cases should be written at requirement gathering stage only i.e., the customer will also be included in writing tests which tends to write the tests regarding acceptance testing...
So the advantage is there is no separate acceptance testing is needed if the application meets all the user requirements.
The disadvantage is when ever there is a change in the requirements the test cases also to be changed but of course it is not a big deal.
Also fitnesse will be suitable for small and medium projects. In case of large projects it could be clumsy because Fitnesse cannot export PDF files it only exports spread sheets like excel or worddoc. So it is a disadvantage that it can't be used for large projects.
From my point of view: it hardly depends on the hooking to the app to be tested. If that doesn't developes a good API, it's almost useless. And don't try it for GUI testing.
Its can be used to run your regression test suites. It can be used to check the database release after release. It can be used to test stored procs. It can be used to compare different environments.
发布评论
评论（5）
NUnit/MbUnit 和 FitNesse 之间的区别在于，NUnit/MbUnit 用于单元测试，而 FitNesse 用于验收测试。
单元测试测试单个小的代码单元（例如方法），以确保它按照程序员的预期执行。 例如，您可以使用单元测试来确保阶乘计算方法返回一组数字的正确结果，包括一些边缘情况。
验收测试旨在测试是否满足高级设计要求。 举个例子，如果您正在编写一个吃豆人克隆，并且其中一个要求是“当上一关卡的最后一个点被吃掉时，新的关卡开始”，那么验收测试将测试该要求是否作为一个整体是由代码满足的——而不是消耗点、检查结束条件和加载新级别的特定代码段（尽管该代码将在运行验收测试的过程中执行）。 验收测试的编写通常不考虑需求的具体实现。
许多 QA 部门手动执行一长串的验收测试，这可能非常耗时。 Fit 和 FitNesse 是帮助自动化验收测试的工具，可以节省大量时间。
Ward Cunningham 的 wiki 中有很多关于验收测试的好信息。
The difference between NUnit/MbUnit and FitNesse is that NUnit/MbUnit are intended to be used for unit tests, while FitNesse is for acceptance tests.
Unit tests test a single, small unit of code, such as a method, to ensure that it executes as the programmer intended. For example, you might use a unit test to ensure that a factorial-computing method returns the correct results for a set of numbers, including some edge cases.
Acceptance tests are intended to test whether a high-level design requirement is met. As an example, if you were writing a Pac-Man clone, and one of the requirements was "A new level begins when the last dot of the previous level is eaten," an acceptance test would test to see whether that requirement as a whole is satisfied by the code--not the specific pieces of code that consume a dot, check ending conditions, and load new levels (although that code would be exercised in the process of running the acceptance test). Acceptance tests typically are written without regard to the specific implementation of the requirement.
A lot of QA departments execute long lists of acceptance tests by hand, which can be very time consuming. Fit and FitNesse are tools that assist in automating acceptance tests, which can save a lot of time.
There's a lot of good information on acceptance tests at Ward Cunningham's wiki.
我合作的最后一家公司使用 FitNesse 并取得了一定程度的成功。 它并不意味着以与 NUnit 相同的方式使用，NUnit 中的测试程度非常精细。 FitNesse 更多地用于“验收测试”，涉及粒度较小的“大规模”测试。 为了比较两者，假设我们正在编写一个用于处理银行支票的应用程序：
如果我们使用 NUnit 编写单元测试，我们将测试 Check 对象、Transaction 对象、TransactionProcessor 工厂的每个单独方法，测试数据访问层的每个方法等。您的测试非常接近源代码。
如果我们正在编写验收测试，我们可能会设置一天的交易，提示应用程序处理交易，并确保代码生成正确的发票报表和报告。 您处于比单元测试高得多的水平，通常处于可以立即测试所有应用程序业务规则的有利位置。
单元测试告诉程序员代码是否包含任何缺陷，验收测试告诉业务分析师应用程序满足用户的期望。
FitNesse 测试用例旨在由没有技术知识的人编写。 您仍然需要程序员编写 DLL 以向 FitNesse 公开应用程序的内部结构，但否则用例应该由对源代码一无所知的非技术人员（即业务分析师和 QA）编写。
我的公司使用 FitNesse 来测试我们的一个“核心”应用程序，该应用程序恰好是使用一种类似 COBOL 的死语言编写了 20 年的时间。 核心应用程序没有单元测试，用原始语言创建单元测试框架几乎是不可能的。 幸运的是，该语言具有 COM 绑定，它向 .NET 和 Java 公开了一些公共方法，使我们能够在 20 年来首次为此应用程序编写自动化测试用例。 它并不漂亮，但商界人士喜欢它。
The last company I worked with used FitNesse with some degree of success. Its not meant to be used in the same way as NUnit, in which the degree of testing is very granular. FitNesse is used more for "acceptance testing", involving less granular, "large scale" tests. To compare the two, lets say we were writing an app for processing checks at a bank:
If we're writing unit tests with NUnit, we'd test each individual method of our Check objects, Transaction objects, TransactionProcessor factories, test each method of our Data Access Layer, etc. You're tests are very close to the source code.
If we're writing acceptance tests, we might set up a days worth of transactions, prompt the app to process the transaction, and make sure that the code produces the correct invoice statements and reports. You're at a much higher level than unit tests, usually at a vantage point where you can test all the applications business rules at once.
Unit tests tell programmers whether the code contains any defects, and acceptance tests tell business analysts that the applications meets user expectations.
FitNesse test cases are designed to be written by people without technical knowledge. You still need programmers to write the DLLs to expose the innards of the application to FitNesse, but otherwise the use cases are supposed to be written by non-technical people who don't know anything about the source code (i.e. business analysts and QA).
My company used FitNesse to test one of our "core" applications, which happened to be written over the course of 20 years using a dead COBOL-like language. The core app did not have unit tests, and it was nearly impossible to create a unit testing framework in the original language. Forturnately, the language had COM bindings which exposed a few public methods to .NET and Java, allowing us to write automated test cases for this application for the first time in 20 years. It wasn't pretty, but the business people liked it.
FitNesse基本上是一个存储所有测试用例的wiki。 最有可能用于验收测试。 在测试优先开发中，测试用例应该仅在需求收集阶段编写，即客户也将参与编写测试，这些测试往往会编写有关验收测试的测试......所以优点是不需要单独的验收测试如果应用程序满足所有用户要求。
缺点是当需求发生变化时，测试用例也会发生变化，但这当然不是什么大问题。
此外，
fitnesse也适用于中小型项目。 对于大型项目，它可能会很笨拙，因为Fitnesse无法导出 PDF 文件，它只能导出 Excel 或 Worddoc 等电子表格。 所以它的缺点是不能用于大型项目。FitNesseis basically awikiwhich stores all the test cases. Most probably for acceptance testing. In Test first development the test cases should be written at requirement gathering stage only i.e., the customer will also be included in writing tests which tends to write the tests regarding acceptance testing...So the advantage is there is no separate acceptance testing is needed if the application meets all the user requirements.
The disadvantage is when ever there is a change in the requirements the test cases also to be changed but of course it is not a big deal.
Also
fitnessewill be suitable for small and medium projects. In case of large projects it could be clumsy becauseFitnessecannot export PDF files it only exports spread sheets like excel or worddoc. So it is a disadvantage that it can't be used for large projects.从我的角度来看：这几乎不依赖于要测试的应用程序的挂钩。 如果不能开发出好的 API，那么它几乎毫无用处。 并且不要尝试将其用于 GUI 测试。
From my point of view: it hardly depends on the hooking to the app to be tested. If that doesn't developes a good API, it's almost useless. And don't try it for GUI testing.
它可用于运行回归测试套件。 可以用来检查数据库发布后的版本情况。 它可用于测试存储过程。 它可以用来比较不同的环境。
Its can be used to run your regression test suites. It can be used to check the database release after release. It can be used to test stored procs. It can be used to compare different environments.