是否有支持从注释生成一些标准单元测试的框架？我想到的一个例子是：
@HasPublicDefaultConstructor
public class Foo {
}
这显然会用于自动生成一个单元测试来检查 Foo 是否具有默认构造函数。我是唯一一个想到过这种事情的人吗？;) 虽然我对 Java 最感兴趣，但其他语言的解决方案肯定也会很有趣。
编辑：针对 S.Lott 的回答，让我澄清一下：
我正在尝试测试该类是否具有默认构造函数。（当然这只是一个例子。）我可以通过编写一个测试来做到这一点，但我觉得这很乏味。所以我正在寻找一种工具，可以在编译时（通过 APT）处理注释并为我生成测试。存在这样的东西吗？如果不是，你认为这是个好主意吗？
问题是使用单元测试信息以附加注释的形式“污染”生产代码是否真的是一个好主意。我个人会投反对票。
听起来您正在寻找一种比标准 Java 更具声明性表达能力的编程语言。您假设的测试填补了空白，直到编译器可以检查声明的语义。
我不知道有任何工具可以将您建议的注释类型转换为自动化测试。不过，这听起来像是一个不错的 TDD 练习，尤其是使用最近的（-ish）编译器 API。
tl;dr：改用代码检查工具。他们可以做你想做的事，不会污染你的代码，并且可以很容易地构建到自动构建过程中。
这听起来不像应该通过单元测试来处理。如果您坚持每个类都必须定义一个默认构造函数，那么静态代码分析器可能是更好的选择。 PMD肯定有这种检测器。您还可以使用Checkstyle强制使用这种检测器。
两者都可以轻松定制，并且可以与单元测试一起成为持续集成过程的一部分。
最关键的一点：这将允许您实现您想要的功能，而不会用额外的注释污染代码库。当我看到这个想法时，这对我来说是一个主要的绊脚石：你创造了一个巨大的软件管理问题。
想象一下使用默认构造函数将类修改为不可变的情况（因此要求在构造过程中完全设置对象）。您还记得更新该课程中的所有这些注释吗？您是否记得更改了调用此方法的其他类中的相关注释？等等。
“处理注释......并为我生成测试”
对于有限数量的情况，这可能会起作用。然而，一般来说，它是行不通的。
@StandardTestForClassHierarchy1
@StandardTestForClassHierarchy2
@StandardTestForClassHierarchy3
@StandardTestForSomeOtherFeature4
@AspectFeature5
@AspectFeature6
@HasPublicDefaultConstructor
@AspectX
@AspectY
class SomeClass extends SomeClassHierarchy implements SomeOtherFeature {
}
我无法区分我的单元测试注释和我的真实注释。
测试注释是否描述了我的应用程序的运行时行为？
如果它们确实描述了运行时行为，那么它们就是真正的 AOP 注释，而不是测试描述，而是真正生成运行时代码的真实注释。并且注释对模拟类有自己的测试。
如果注释没有描述运行时行为，那么我现在就会遇到这种奇怪的杂乱无章的非功能性和功能性注释。我没有看到非功能注释中的价值。
有点类似于您为测试默认构造函数的存在所描述的内容，我使用TestUtil来自动测试 getter 和 setter。您可以使用 XML 文件或 JavaDoc 标记来调整测试选项。遗憾的是，目前似乎没有注释选项。
对于您的具体示例，最好在编译时更早地使用 java APT（编译时注释处理）来检测此类问题。
我认为您不太可能自救。但是你会增加复杂性。
如果我想确定有一个默认构造函数，我会将以下内容添加到我的单元测试中。
Foo foo = new Foo();
您可以在编译时使用 APT 检测到这一点。
这可能是您正在寻找的：http: //developer.spikesource.com/wiki/index.php/Projects :testgen4j 。其他可能有用的链接：http ://www.opensourcetesting.org/unit_java.php 。这是一篇当前的论文：http ://www.alexquinn.org/papers/Generating%20Java%20unit%20tests%20with%20AI%20planning%20(2007).pdf
EiffelStudio CDD 有一个有趣的方法。在调试模式下运行时，IDE 会收集有关被调用方法的信息，并将上下文和调用放入单元测试中。使用按合同设计来检测故障。我知道在 Java 之上有一些按合同扩展的设计，所以这可能是一个不错的方法。