【问题标题】:creating unit tests (semi-)automatically?自动创建单元测试(半)?
【发布时间】:2010-09-28 14:55:27
【问题描述】:

是否有支持从注释生成一些标准单元测试的框架?我想到的一个例子是:

@HasPublicDefaultConstructor
public class Foo {

}

这显然会被用来自动生成一个单元测试来检查 Foo 是否有一个默认的构造函数。我是唯一一个想到过这种事情的人吗? ;) 虽然我对 Java 最感兴趣,但其他语言的解决方案肯定也会很有趣。

编辑:针对 S.Lott 的回答,让我澄清一下:

我正在尝试测试该类是否具有默认构造函数。 (当然这只是一个例子。)我可以通过编写一个测试来做到这一点,但我觉得这很乏味。所以我正在寻找一种工具,可以在编译时(通过 APT)处理注释并为我生成测试。 存在这样的东西吗?如果不是,您认为这是个好主意吗?

【问题讨论】:

    标签: java unit-testing automation code-generation annotations


    【解决方案1】:
    【解决方案2】:

    EiffelStudio CDD 有一个有趣的方法。在调试模式下运行时,IDE 会收集有关被调用方法的信息,并将上下文和调用放入单元测试中。使用按合同设计来检测故障。我知道有一些基于 Java 的合约扩展设计,所以这可能是一个不错的选择。

    【讨论】:

      【解决方案3】:

      对于您的具体示例,最好在编译时更早地使用 java APT(编译时注释处理)来检测此类问题。

      【讨论】:

        【解决方案4】:

        Agitar 有一个 [商业] 产品 AgitarOne,可以生成 JUnit 测试。 我不确定它目前是否支持注释,它didn't in 2005

        Jtest 是另一个面向 Java 的单元测试生成器,Parasoft 还提供 C++Test 来生成 C++ 单元测试。

        我从来没有测试过它们中的任何一个;几年前我读过 C++Test 论文,但并不相信。

        【讨论】:

          【解决方案5】:

          问题是,以附加注释的形式用单元测试信息“污染”生产代码是否真的是个好主意。 我个人会投反对票。

          【讨论】:

          • 除了 Snyke 指出的 - 开发人员在编写单元测试时不应该更加注意吗?通过使用生成的测试或半块单元测试,您可以获得半块功能。 ;-) 在最好的情况下,您可以期待单元测试框架,以便您更快地实现更高的代码覆盖率。
          【解决方案6】:

          有点类似于您所描述的测试默认构造函数的存在,我使用TestUtil 自动测试getter 和setter。您可以使用 XML 文件或 JavaDoc 标记来调整测试选项。遗憾的是,目前似乎没有注释选项。

          【讨论】:

            【解决方案7】:

            “处理注释......并为我生成测试”

            对于数量有限的情况,这可能会起作用。但是,一般来说,它是行不通的。

            @StandardTestForClassHierarchy1
            @StandardTestForClassHierarchy2
            @StandardTestForClassHierarchy3
            @StandardTestForSomeOtherFeature4
            @AspectFeature5
            @AspectFeature6
            @HasPublicDefaultConstructor
            @AspectX
            @AspectY
            class SomeClass extends SomeClassHierarchy implements SomeOtherFeature {
            }
            

            我无法区分我的单元测试注释和我的真实注释。

            测试注释是否描述了我的应用程序的运行时行为?

            • 如果它们确实描述了运行时行为,那么它们就是真正的 AOP 注释,而不是测试描述,而是真正生成运行时代码的真正注释。并且注解在模拟类上有它自己的测试。

            • 如果注释 描述运行时行为,我现在就会遇到这种奇怪的杂乱无章的非功能性和功能性注释。我没有在非功能性注释中看到价值。

            【讨论】:

              【解决方案8】:

              听起来您正在寻找一种比标准 Java 更具声明性表达能力的编程语言。您假设的测试填补了空白,直到编译器可以检查声明的语义。

              我不知道有任何工具可以将您建议的注释类型转换为自动化测试。不过,这听起来像是一个不错的 TDD 练习,尤其是使用最近的(-ish)编译器 API。

              【讨论】:

                【解决方案9】:

                您可以在编译时使用 APT 检测到这一点。

                http://www.javaspecialists.eu/archive/Issue167.html

                【讨论】:

                  【解决方案10】:

                  tl;dr: 改用代码检查工具。它们可以做您想做的事,不会污染您的代码,并且可以轻松构建到自动构建过程中。

                  这听起来不像应该通过单元测试来处理。如果您坚持每个类都必须定义一个默认构造函数,那么静态代码分析器可能是更好的选择。 PMD 肯定有这种事情的检测器。您也可以使用Checkstyle 强制这种检测器。

                  这两者都可以轻松定制,并且可以与单元测试一起成为持续集成过程的一部分。

                  最关键的一点:这将允许您实现您想要的功能,而不会用额外的注释污染代码库。当我看到这个想法时,这对我来说是一个主要的绊脚石:你创造了一个巨大的软件管理问题。

                  想象一下使用默认构造函数将类修改为不可变的情况(因此需要在构造过程中完全设置对象)。您还记得更新该课程中的所有这些注释吗?您是否记得更改了其他调用此方法的类中的相关注释?以此类推。

                  【讨论】:

                    【解决方案11】:

                    我认为您不太可能自救。但是你会增加复杂性。

                    如果我想确定有一个默认构造函数,我会将以下内容添加到我的单元测试中。

                    Foo foo = new Foo();
                    

                    【讨论】:

                      猜你喜欢
                      • 1970-01-01
                      • 2014-03-14
                      • 1970-01-01
                      • 1970-01-01
                      • 1970-01-01
                      • 2016-06-21
                      • 1970-01-01
                      • 1970-01-01
                      • 2019-12-01
                      相关资源
                      最近更新 更多