为什么用 testFixture 而不是 TestClass？答案

【问题标题】：Why testFixture instead of TestClass?为什么用 testFixture 而不是 TestClass？
【发布时间】：2010-07-05 04:55:45
【问题描述】：

可以通过三种方式组织单元测试：按夹具、类或功能进行测试。但是 TestClass 的 NUnit 属性称为 TestFixture。有什么历史原因吗？

【问题讨论】：

标签： nunit

【解决方案1】：

我尊重 Mike Two 的回应，但我要断言 NUnit 团队在这方面做得非常错误，[TestFixture] 的使用是 NUnit 脸上的一个语义缺陷。 测试类不是固定装置。根据我对 JUnit 的研究，我没有发现任何将测试类作为测试夹具的参考，也没有发现很多关于“测试夹具”指代测试类的讨论。相反，所有关于夹具的 JUnit/xUnit 讨论都与设置和拆卸有关，这当然是用于设置实际测试夹具的常用方法。

请注意，在 NUnit 2.5 中，您可以删除 [TestFixture] 注释。

更新：（2012 年 7 月）

我正在阅读 Cucumber Book，在第 99 页，作者 Matt Wynne 解释了使用“夹具”的起源。我引用：

将测试系统和被测系统之间的链接称为夹具是一个悠久的传统（来自硬件世界，即测试夹具的起源地）。这就是我们在本书中称为自动化代码的“粘合代码”角色。 FIT 测试框架使用该术语的这个含义。一些单元测试工具（例如 NUnit）通过将测试用例类本身称为夹具，进一步混淆了这个问题。对于一种无处不在的语言来说就是如此！（Wynne & Hellesoy，2012 年）

【讨论】：

我同意你的看法。那是一个错误。一旦到了那里就很难收回。但是我确实认为当时 JUnit 中有类似的行为。我可能完全错了。这一切都发生在 2002 年初，我可能记错了。无论哪种方式，您都认为测试类和夹具是不同的东西是正确的。
感谢 Mike Two，我一直对我们工艺项目背后的传奇历史着迷。我也意识到，如果我不喜欢它，我不应该抱怨，而是提交一个补丁。我只是想知道我是否过于迂腐，因为迄今为止没有其他人对 NUnit 进行过这种更改。
我考虑过改变它几次。我遇到了向后兼容性问题。几年前我停止了常规的 NUnit 工作，所以我不打算在未来改变它。

【解决方案2】：

主要的历史原因是 NUnit 最初是作为 JUnit 的直接端口而诞生的，而 junit 将其称为测试夹具。

NUnit 1.0 早于我的时代，但有人告诉我它是通过将 JUnit 中的所有 .java 文件重命名为 .cs 文件并尝试编译来开始的。它是从那里修复的，并添加了一个 UI。当我加入 NUnit 2.0 时，NUnit 1.0 中仍有一个名为 IsVisualAgeForJava 的方法，因为当时 JUnit 对此有特殊行为。

在 NUnit 2.0 中，我们的目标是让 NUnit 更加 .NETish。所以我们添加了属性和一堆其他的东西。我们所有人都来自 java 背景，并且已经使用 JUnit 多年。使用[TestFixture] 似乎很自然。

【讨论】：

【解决方案3】：

既然你问了，我就查了一下。
测试夹具是在运行测试之前必须建立的固定基线状态，以便结果是可预测和可重复的。在单元测试框架中，我们使用 SetUp 和 TearDown 属性/方法来创建/销毁测试夹具（例如，使用正确的对象初始化实例变量）。

【讨论】：