将测试方法放在您正在测试的同一个类中有什么问题吗？

Question

将测试方法放在与您正在测试的类相同的类中是否有任何问题？

因此，将[TestFixture]属性添加到每个类中，并将[Test]方法与实际方法一起使用。

我喜欢这个主意。把所有东西放在一个地方。

但是，如果有的话，这是什么缺点呢？

/我使用Nunit和c＃。

Answer 1

是的，这是一个需要避免的模式。至少出于以下原因，测试应该是与您的运输代码完全独立的实体

• 在单独的程序集中进行测试有助于确保您拥有可用的API，因为他们无法通过private / protected构造作弊。相反，他们被迫通过公共API点
• 在同一个程序集中进行测试意味着您的生产代码还包含您的测试代码。没有理由将代码发送给他们实际上不会使用的客户
• 使生产代码依赖于他们不需要的程序集（Nunit，xunit等......）
• 许多测试框架要求测试方法公开，因此它会将测试推送到API的公共表面。
• 将它们放在同一个程序集中会打开生产代码的大门，意外地调用测试代码，从而在生产环境中弹出有趣的断言

Answer 2

这种方法激励了我的灵魂。

我认为将测试代码与生产代码分开会更有意义。原因很多：

• 从理论上讲，您应该在代码的界面进行测试，而无法访问幕后私人成员等内容。
• 组织 - 将所有测试都放在一个单独的项目中意味着您的主应用程序不会被测试代码弄得乱七八糟。
• 这会使你的可交付成果变得臃肿。
• 将所有内容放在一个地方会让团队更难同时处理代码库（一个人在测试，一个人在代码上等）。

最重要的是：

只是平原感觉/气味错误。

Answer 3

是。这将打破单一责任原则。它会降低可读性。您将依赖项添加到测试框架中。

Answer 4

最大的缺点：您必须发送测试，并且它们可能成为您的公共API的一部分。

Answer 5

缺点？

您的类在技术上将拥有比在生产环境中使用所需的方法更多的方法。您还将在生产环境中引用nUnit。

你也在这里打破职责分离。你的班级应该完成这项工作，你的考试应该验证你的班级能否胜任。

Answer 6

一个潜在的缺点是，当您运送代码时，您还必须运送所有测试，使可交付的二进制文件变得更大，充满了永远不会被调用的测试方法。

更具哲学性的缺点是，虽然您确实将所有内容保持在一起，但您未能将代码本身（业务逻辑）的关注点与质量保证的关注点分开（确保其正常工作）。尝试根据每个类/文件的单一责任来考虑您的代码，并查看它的用途。

Answer 7

你不想走快捷方式。

您不想测试私有方法。您尤其不希望将私有方法用作单元测试的辅助方法（即，在测试中重用它们）。

在测试项目中对测试类进行分组要好得多。这些不会影响正在测试的代码，并且更容易概述您拥有的代码。

以同样的方式，您不会混合UI和业务逻辑代码。

所以，请，请相当，请不要将测试与他们的测试对象混合！

Answer 8

我看到的最大问题是，您不希望在代码库中分发单元测试作为最终产品的一部分（因此也是依赖性）。

在这种情况下，使用跟踪常量有条件地构建它们会变得非常丑陋。例如，测试夹具属性的一个条件和方法或方法组的至少一个条件。

有很多方面可以解释为什么不这样做，如已经泛滥的答案数组中所示 - 就是不要这样做。

Answer 9

投入我的两分钱：

我同意这里的大多数帖子，说明为测试的唯一目的创建测试方法/功能是浪费的，并且可能在结构上混乱。

但是，一般而言，当您开发“考虑到测试”时，您可以设计您的实现以进行测试。例如，您最初可能会设计一个函数/方法来使用类变量。但是，如果您想测试该方法的功能，可以将其设计为将类变量的值“传入”作为函数参数。

现在你的方法功能齐全，可以测试，即功能测试。

所以，你可以设计你的课程以便以后进行测试，同时不会因为测试的唯一目的而创造一个方法的所有负面因素。

我希望这会有所帮助。这个wiki给出了编程测试的一个很好的概述，一般来说： http://en.wikipedia.org/wiki/Software_testing

Answer 10

是。首先，它使您的类更大 - 测试使用的每个属性或字段必须在内存中随处使用。其次，它为类添加了一堆公共方法和属性，这些方法和属性对于像工厂这样的东西是可见的。

如果您希望您的测试与您的课程一起使用，只需将它们放在同一个文件中：

public class Foo : IFoo
{
    ...
}

[TestFixture]
public class Foo_Tests
{
    ...
}