自我测试代码与独立测试的优势是什么?

也许拥有自我测试代码有点优雅,但我倾向于站在和您相同的哲学一边——代码分离胜过抽象美的概念。当您设计一个类时,可以从根本上将它分成三个部分:

• 类的作用(如类的定义)
• 如何实现(实现)
• 如何使用它(文档和/或测试用例)

我将测试用例视为文档的目的,也是测试套件中安全网的一部分。当一个新的程序员正在查看您的代码时,可能在您停止使用它很久之后,文档很少是沟通如何使用类的最有效的方式。它可以回答有关代码在特定情况下的行为的问题,提供类及其方法的一般概述,等等,但是测试用例提供了一个具体的例子,说明如何在 实数编码 .

因此,出于这个原因,我倾向于说,他们应该保持在阶级之外,因为这重新加强了这种分离的程度。

将它们放在正在测试的同一类中可能会破坏流行的单元测试框架,因为nunit不会测试没有默认无参数构造函数的类型。

将测试放在不同的文件中,但相同的项目更好,但仍然会导致主项目引用测试框架(如nunit.framework.dll)和模拟框架(如rhino.mocks.dll)。

将测试放在受测试的类中也会增加分布式项目的大小。

将测试分离到一个单独的项目中,您没有任何这些问题。

将测试保存在一个单独的区域(子目录、项目、任何内容)中是保留部署选项的好方法 只是 生产代码,这通常是您想要做的。

在测试的同一个类中进行测试非常方便。通常(在开始TDD之前),我使用向类中添加一个主要方法来测试我编写的代码的功能。我没有删除主方法,因为让测试代码放在旁边非常有用。这很方便,从同样的意义上说,将文档绑定到代码上也很方便。我不需要在其他地方查找或搜索测试代码。

尽管如此,TDD的重点不仅仅是测试/质量保证。更重要的是让你思考你的设计/界面。从这个角度来看,将“测试”(也称为“设计”)代码放在单独的文件中是有意义的。您的“测试”代码是类的客户机/用户。

如果在单独的文件中编写测试的目的是技术性的,即“因为单元测试框架是以这种方式设计的”,或者“否则,您将需要在主项目中包含一个引用”,或者“它提高了性能”,这听起来不是很有说服力。如果是这样的话,事情就会完全不同。

我认为在同一类中使用测试代码和生产代码没有任何好处。相反,我看到了一些缺点:

• 如果没有测试代码,就不可能部署和分发生产代码。因此,您可能需要发送200KB或更大的文件,而不是100KB文件。(使用TDD时,测试代码行通常等于或大于生产代码行。)

• 测试的结构与生产代码的耦合过于紧密。测试和生产等级之间不应存在1:1的关系。相反,测试和行为之间应该有1:1的关系。

引用自 http://blog.daveastels.com/files/BDD_Intro.pdf

“当您意识到这一切都是关于指定行为而不是编写测试时,您的观点就会改变。突然间,为每个生产类都创建一个测试类的想法受到了荒谬的限制。而用自己的测试方法(在1-1关系中)测试每个方法的想法将是可笑的。”

我主要用Java编程,我用Maven来构建我的项目。在那里,我在同一个模块和包中进行测试,作为它们运行的生产类,但是在不同的目录(/SRC/Ma/Java和/SRC/Test/Java)中。当Maven构建项目时,它执行所有测试,但二进制可分发文件中只包含生产代码。

我认为这主要是哲学上的不同。

将它们放在单独的项目中可能会有边际的性能优势(因为您的测试没有部署到生产中),但它们可能没有 那个 意义重大。

还要记住 重构 很早以前就写了(用IT术语来说),所以从那时起,首选的实践可能已经开始了。