应该JUnit测试javadocced？

15

如果测试的目的很明显，我不打算记录它。

如果它不明显，因为它处理一些不明确的情况 - 或者如果我想参考一个特定的错误，例如 - 在那 case我会添加文档。虽然我没有记录异常抛出等 - 只是对方法的快速总结。这很少发生。我更可能为多个测试中使用的助手方法添加文档。

来源

2009-11-26 16:19:35

+0

我同意你的意见。我讨厌看到单元测试不清楚他们正在测试什么。代码随着时间而改变，原始原因可能不明显。 –

+1

我宁愿在每个assertFoo语句中看到一个说明字符串。 –

10

我在javadocing测试用例中找不到任何值。我只是将方法名称描述得足以知道测试的目的。

在Ruby中，我知道有些工具可以从测试名称创建文档，但是我没有在Java中看到过其中的一个。

来源

2009-11-26 16:10:50

1

我不明白为什么您应该将测试用例与您的生产代码关于注释的处理方式有所不同。

来源

2009-11-26 16:12:41 JesperE

+0

但是正如上面提到的Kaleb，如果名称足够冗长，那不就是多余的吗？ – Jim

+0

正确命名的标识符不能替代评论。 – JesperE

3

无论javadoc与否，我认为单元测试一定要记录下来。在没有正式规范的情况下，单元测试最接近于定义代码的预期行为。通过记录测试用例，您将会向读者明确测试的内容以及测试的原因。

来源

2009-11-26 16:13:15 omerkudat

+0

完全同意你的看法。我也一样。我将该方法命名为test [MethodUnderTest] _Should [ExpectedBehavior] _When [Scenario]。所以这就是文档本身。加上我应该包含在产品文档中的javadoc行为。 –

1

我认为javadoc测试通过的条件很有价值。

来源

2009-11-26 16:24:02

2

在考虑作为文档的测试时，“记录文档”没有多大意义。每个测试的名称本身应该已经描述了测试的目的是什么 - 该测试指定的行为是什么。

使用长的描述性名称进行测试，并尽可能保持测试代码的可读性。

例如看看测试案例in this project。通过查看测试的名称和测试代码，他们中的任何一个是否做了一些并不明显的事情？

只有在极少数情况下，当测试代码不清晰时，测试中需要注释。例如，如果您正在测试多线程代码，并且测试代码会执行奇怪的操作，以确保测试代码以正确的顺序运行。但即使在这些情况下，a comment is an apology也不会写出更清晰的测试代码。

来源

2009-11-26 16:30:12

0

地狱是啊。即使它只是...

创建订单，编辑订单，保存，加载&检查它。

如果它是一个非常简单的测试，那么也许不是。

我发现，随着代码的变化，有时测试的原因并不像以前那样明显。

来源

2009-11-26 16:30:42

0

也许你可能会找到一个对你的代码不完全熟悉的人，来告诉你一些关于你的测试是否易于理解的快速反馈。

在我工作的公司，我们尝试给我们的测试描述性名称和文档复杂性，但通常很难在第一稿中得到这个“正确”，因为对开发人员来说显而易见的事情并不总是很明显给他人。

测试被视为代码并作为同行评审过程的一部分提交，所以我们的（小）团队可以评论测试是否易于理解。

如果测试有点令人困惑，我们可以相应地更新名称或文档，我们会更好地评估什么是有效的，哪些没有。

来源

2009-11-26 16:52:26 analogsilence

1

建议代码注释是反模式是异端吗？我同意上述答案，理想情况下，您的代码足以描述性地依赖于没有评论的内容。如果您处于（企业）环境中，人们倾向于更新代码而不更新注释，则注释会变得具有误导性，这一点尤其如此。

来源

2009-11-30 21:34:48

应该JUnit测试javadocced？

回答

相关问题