为什么用testFixture代替TestClass？
有三种组织单元测试的方法：根据夹具，类或特征进行测试。但TestClass的NUnit属性称为TestFixture。这有什么历史原因吗？为什么用testFixture代替TestClass？
主要的历史原因是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]似乎很自然。
现在你问了一下，我只是查了一下。
测试夹具是在测试运行之前必须建立的固定基线状态，因此结果是可预测和可重复的。在单元测试框架中，我们使用SetUp和TearDown属性/方法创建/销毁测试夹具（例如，使用正确的对象初始化实例变量）。
我尊重Mike Two的回应，但我会断言NUnit团队得到这个错误，并且使用[TestFixture]是NUnit面对的语义瑕疵。 测试课不是夹具。从我在JUnit中挖掘到的内容，我没有发现任何测试类的引用作为测试工具，也没有发现关于测试类的“测试工具”的讨论。相反，所有有关灯具的JUnit/xUnit讨论都与设置和拆卸有关，当然，这是用于设置实际测试设备的常用方法。
请注意，在NUnit 2.5中，您可以删除[TestFixture]注释。
更新：（2012年7月）
我只是读的书黄瓜和99页上，作者马特·怀恩说明使用的原产地“固定”。我引用：
有一个很长的传统（来自硬件世界，测试设备起源于）调用测试系统和被测系统之间的链接。这是我们在本书中称为自动化代码的“胶水代码”角色。 FIT测试框架使用该术语的这个含义。 一些单元测试工具（如NUnit）通过将测试用例类本身作为一个固定装置来进一步混淆了这个问题。非常适合无处不在的语言！ （Wynne & Hellesoy，2012）
我同意你的意见。那是一个错误。一旦它在那里就很难收回。不过，我认为当时JUnit中存在类似的行为。我可能完全错误。这一切都在2002年初，我可能会错误地记住它。无论哪种方式，你的断言是正确的，即测试类和夹具是不同的东西。 – 2012-05-20 10:48:38
感谢Mike Two，我总是着迷于我们工艺项目背后的传奇历史。我也意识到，如果我不喜欢它，我不应该抱怨，而是提交一个补丁。我只是想知道我是否过于迂腐，因为迄今为止没有其他人对NUnit进行过这种更改。 – ybakos 2012-05-20 19:57:15
我曾考虑改变它几次。我遇到了向后兼容问题。我几年前就停止了NUnit的正常工作，所以我不打算在将来改变它。 – 2012-05-20 20:37:54