NUnit与手动单元测试

Question

背景

我最近尝试为特定应用程序的回归测试开发一套测试。我一直在使用NUnit并没有遇到任何问题。

我遇到了向NUnit测试发送参数的问题，但似乎没有令人满意的答案。

问题

假设我实现了一个加载类的简单单元测试器，按顺序运行Startup，Test和Teardown方法，捕获异常然后卸载程序集。与使用NUnit相比，这样做有什么缺点？

在这种情况下，我可以轻松地将参数传递给我的测试用例，或做任何其他我可能想到的疯狂的事情。但我担心的是我放弃NUnit会失去的东西。

Answer 1

你输了什么？你的时间。

如果您是为客户或企业工作，他们（大概）会付钱给您解决业务问题，而不是编写基础架构代码。为满足业务需求，可能需要一些基础设施。在这种情况下，它显然不是。你正在重新发明轮子。

不要陷入Not Invented Here陷阱。使用NUnit。它支持parameterized tests。如果NUnit无法满足您的需求，请调查MbUnit or xUnit.net。或者查看SpecFlow等BDD风格。或FitNesse进行验收测试。这只是部分清单！

如果您是出于学习目的自己编写测试框架，那太好了！如果没有，你就是在浪费你的时间和/或你公司的钱。

解决技术问题

JUnit最初是在long airplane trip期间创建的。那时候没有很多选择。编写测试框架并不是一个庞大的项目。编写功能强大且易于使用的强大功能更加困难。编写测试运行器，IDE集成，CI集成，代码覆盖集成等要困难得多。 已经完成了。除非你是Ayende Rahien，否则不要这样做！

除了集成之外，您还会丢失任何未实现的features of NUnit（并且有很多）。我没有使用所有这些，但我确实依赖它们中的许多。

（从我的评论中移出）

Answer 2

此问题主要分为两个部分：

• 创建我们自己的实现的利弊
• 为什么这个用例甚至没有理由去创造自己的想法 实施

---

1）因为这属于“车轮的重新发明”，所以所有优点/缺点都比这个问题相同，而且笼统得多，所有推理都适用于这种情况。

• 我们没有利用现有的稳定实施方式
• 我们可能低估了在现有实施中投入的工作时间
• 我们失去了所有周围的生态系统，这些周围的生态系统都是基于现有实施方式构建的
• 我们失去了共同积累的社区知识
• 可能我们将无法在可接受的时间内达到所需的最低质量要求

（在1990年代，我遇到了一个写RDBMS的人，因为Oracle数据库和SQL Server 6.5都“无法”执行他想做的事情……这是一个可分页的游标）

2）将参数发送到NUnit测试就像其他任何配置/参数设置任务一样。您可以从您选择的格式（例如：XML，json，RDBMS）中读取配置/参数，并在设置，拆卸和“测试”方法中进行操作。

您可以创建

• a）完全自定义的实现（我的意思是在 设置，测试和拆卸）
• b），或者您可以依靠[TestCaseSource]或 一些相关属性
• c）或 extend NUnit