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

| 将测试方法与要测试的类放在同一类中有什么问题吗？因此，将[TestFixture]属性添加到每个类，并在实际方法旁边添加[Test]方法。我喜欢这个主意。将所有内容都放在一个地方。但是，这样做的不利之处是什么呢？ /我使用Nunit和c＃。

已邀请:

10 个回复

辰炔诚薯

是的，这是要避免的模式。至少出于以下原因，测试应该是与您的运输代码完全独立的实体在单独的程序集中进行测试有助于确保您拥有可用的API，因为它们无法通过private/protected构造作弊。相反，他们被迫通过公共API点在同一程序集中进行测试意味着您的生产代码也包括您的测试代码。没有理由将代码发送给他们实际上不会使用的客户使生产代码依赖于不需要的程序集（Nunit，xunit等...）许多测试框架要求测试方法是公开的，因此会将测试推送到API的公开表面。将它们放在同一程序集中为意外调用测试代码的生产代码打开了大门，因此乐趣在生产环境中突然弹出

丧泉缝锋

这种方法使我心碎。我认为将测试代码与生产代码分开会更有意义。很多原因：从理论上讲，您应该在代码的界面上进行测试，并且不能访问幕后的私有成员之类的东西。组织-在单独的项目中拥有所有测试，这意味着您的主应用程序不会被测试代码所困扰。这将使可交付成果的大小膨胀。将所有内容放到一个地方会使团队很难同时在代码库上工作（一个人进行测试，一个人进行代码，等等）。最重要的是：只是平原感觉/闻错。

碧肮械淌设

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

细屠截殴些

最大的缺点：您必须交付测试，并且这些测试可能会成为公共API的一部分。

搜洼挂时

缺点？从技术上讲，您的课程所使用的方法将超过在生产环境中使用的方法。您还将拥有在生产环境中不需要的对nUnit的引用。您也在这里打破职责分工。应该让您的班级完成这项工作，而应该通过测试来验证您的班级可以完成其工作。

蹄渭信妥扳

一个潜在的缺点是，在交付代码时，还必须交付所有测试，从而使可交付二进制文件更大，充满了从未被调用的测试方法。从哲学上来说，更糟的是，尽管您确实将所有内容保持在一起，但是您没有将代码本身（业务逻辑）的关注与质量保证（确保其正确运行）的关注分开。尝试根据对每个类/文件的单一责任来考虑代码，并了解将您带到何处。

抽法

您不想采取捷径。您不想测试私有方法。您尤其不想将私有方法用作单元测试的辅助方法（即在测试中重用它们）。在测试项目中对测试类进行分组会更好。这样，它们就不会影响正在测试的代码，并且更容易掌握所拥有的代码。您不会以相同的方式混合UI和业务逻辑代码。因此，请，请，相当请，不要将测试与他们的测试对象混合使用！

青董据零

我想到的最大的问题是，您不想将单元测试作为最终产品的一部分分发到您的代码库中（因此也有依赖性）。在这种情况下，使用跟踪常量有条件地构建它们会变得很丑陋。例如，测试夹具属性的一个条件，方法或方法组的至少一个条件。有许多方面与为什么不这样做有关，例如已经大量涌入的答案中所说明的-只是不要这样做。

锹缄

投入我的两分钱：我会同意这里的大多数文章，指出仅出于测试目的而创建测试方法/功能是浪费的，而且可能在结构上是混乱的。但是，通常，在开发“考虑到测试”时，可以将实现设计为也要进行测试。例如，您可能最初设计了一个函数/方法来使用类变量。但是，如果您想测试该方法的功能，则可以将其设计为将类变量“传递给”的值作为函数参数。现在您的方法是可以测试的，即功能测试。所以说真的，您可以设计您的类以便以后进行测试，而不会因为创建测试的唯一目的而遭受创建方法的所有负面影响。我希望这有帮助。通常，该Wiki很好地概述了编程测试： http://en.wikipedia.org/wiki/Software_testing

豪抱怒掳

是。首先，它使您的类更大-测试所使用的每个属性或字段都必须随处使用您的类的内存中携带。其次，它向类添加了一堆公共方法和属性，这对于工厂等事物是可见的。如果您希望您的测试与您的课程一起使用，只需将它们放在同一文件中：

public class Foo : IFoo
{
    ...
}

[TestFixture]
public class Foo_Tests
{
    ...
}

要回复问题请先登录或注册

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

10 个回复

发起人

c#

unit_testing

nunit

问题状态

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

与内容相关的链接

10 个回复

发起人

c#

unit_testing

nunit

问题状态