我有许多JUnit测试用例，目前没有用Javadoc注释记录。
我的其余代码都有记录，但我想知道是否值得努力记录这些测试。
答案 0 :(得分：15)
如果测试的目的很明显，我不打算记录它。
如果它不明显，因为它处理一些模糊的情况 - 或者如果我想引用特定的错误，例如 - 在 情况下我会添加文档。我不记录异常抛出等 - 只是方法的快速摘要。这相对很少发生。我更有可能为多个测试中使用的辅助方法添加文档。
答案 1 :(得分：11)
我在javadocing测试用例中没有找到任何价值。我只是让方法名称描述得足以了解测试的目的。
在Ruby中，我知道有些工具可以从测试名称创建文档，但我还没有在Java中看到过这些文档。
答案 2 :(得分：3)
无论是否javadoc，我认为单元测试肯定应该记录在案。在不存在正式规范的情况下，单元测试最接近于定义代码的预期行为。通过记录测试用例，您将使读者清楚地了解测试测试的内容，以及测试测试的原因。
答案 3 :(得分：2)
当将测试视为文档时，“记录文档”没有多大意义。每个测试的名称本身应该已经描述了测试的目的是什么 - 该测试指定的行为是什么。
为测试使用长的描述性名称，并使测试代码尽可能可读。
例如，查看测试用例in this project。通过查看测试名称和测试代码，他们中的任何人是否做了一些不明显的事情？
仅在极少数情况下，当测试代码模糊不清时，测试中需要注释。例如，如果您正在测试多线程代码，并且测试代码做了奇怪的事情，以确保测试代码以正确的顺序运行。但即使在这些情况下，a comment is an apology也没有编写更清晰的测试代码。
答案 4 :(得分：1)
我不明白为什么你应该以与评论相关的生产代码不同的方式处理测试用例。
答案 5 :(得分：1)
我认为javadoc测试通过的条件是有价值的。
答案 6 :(得分：1)
建议代码注释是反模式是否是异端？我同意上述答案，理想情况下，您的代码将具有足够的描述性，可以依赖于没有评论。如果您处于（企业）环境中，人们倾向于在不更新注释的情况下更新代码，那么评论就会产生误导性，这一点尤其如此。
答案 7 :(得分：0)
创建订单，编辑订单，保存，加载＆amp;检查一下。
如果它是一个非常简单的测试，那么也许不是。
我发现随着代码的变化，有时测试的原因并不像以前那样明显。
答案 8 :(得分：0)
也许你可以找到一个不完全熟悉你的代码的人，给你一些关于你的测试是否易于理解的快速反馈。
在我工作的公司，我们尝试为我们的测试提供描述性名称和文档复杂性，但通常很难在初稿中获得“正确”，因为开发人员显而易见的事情并不总是显而易见的其他
测试被视为代码，并作为同行评审过程的一部分提交，因此我们（小）团队可以评论测试是否易于理解。
如果测试有点令人困惑，我们可以相应地更新名称或文档，我们会更好地衡量哪些有效，哪些无效。