Question

作为it happens with private methods，只有谁有权访问源代码才能看到单元测试方法文档。是否值得花费在它上面的努力？

通过文档我的意思是（但更具描述性）：

/// <summary>
///A test for SomeClass.SomeMethod
///</summary>
[TestMethod()]
public void SomeMethodTest()
{
}

Answer 1

单元测试的目标应该是自我描述，但总会出现无法实现这一目标的情况，因此对所写内容的描述即将到期。

换句话说，尝试进行单元测试，这样他们就不需要文档，但如果需要，请写下来！

Answer 2

我宁愿倾向于说你应该以一种表达方式对你的测试方法进行命名：SomeMethodWillBehaveThisWayWhenCalledWithTheseParameters()虽然有些人可能会发现有争议的。

Answer 3

哦，是的！

即使“有权访问源代码的人”永远不会成为除了你以外的任何人，但是在一年内（甚至从现在开始的一个月内）看它就不一样了，相信我那个： - ）

Answer 4

您应记录所有代码。

对于单元测试，我通常说我正在测试，和它是如何测试的。将“Test for Class.someMethod”放在一起并不是很有帮助。

Answer 5

是。我认为记录单元测试是一个好主意的原因是，在开发期间，如果您不仅修改生产类的API，而且修改导致某些测试失败的一些内部行为，那么它可以节省相当多的时间来导航到测试代码，阅读单元测试文档，并确定您是否会预期测试失败，因为您最近的行为发生了变化，或者可能发生了更微妙的事情。

如果没有此文档，您必须从其名称和测试中的注释/代码中找出测试的作用。

请注意，如果你只想在文档中重写单元测试的名称，那么这不是很有用，我坚持只给单元测试一个描述性的名称（即文档应该是比单元测试的名称更详细）

Answer 6

我认为记录单元测试是好的，我的主要原因是你可以解释为什么要测试特定的功能。我的单元测试往往会出现各种奇怪的极端或意外参数。

如果测试失败，未来的程序员（或者内存不良）会知道为什么功能已经过测试/实现。

Answer 7

是。测试可能看起来像是自我记录的，但是你有时必须经历的有关产生有意义的测试数据的循环意味着对于最终的维护者来说，一切都可能不会立即显而易见，而维护者可能就是你！让您的生活更轻松 - 记录您的代码。

Answer 8

单元测试应该足够简单并且足够冗长以使其易于理解。如果您需要评论您的单元测试，也许您应该更改其名称，或者你应该把它重构成更小的方法。

重构测试是一种很好的做法，你必须实际重构你的测试，否则它们将无法维护。

我看到它们的评论几乎总是表明你应该重构那段你需要评论的代码。适用于生产代码的内容适用于测试代码。

Answer 9

大多数单元测试不需要文档。该名称应该清楚它们测试哪种方法并给出预期结果的指示。代码应该简单明了。单元测试不应该实现业务规则，因此通常不需要记录“为什么”。

在极少数情况下，测试必须足够复杂以保证注释，它们应该像任何其他代码一样记录在案。

Answer 10

对于MSTest（IDK，如果NUnit有类似的东西），每个测试方法的DescriptionAttribute都很有用，因为它们出现在Visual Studio的测试结果面板上。比命名约定更可读当WhenThisHappenShouldHappenThis。

Answer 11

我发现单元测试打印出来的消息一般就足够了。例如，在Perl中：

is(compare_bitstrings($bs1, $bs2, $gen), 1, 'compare_bitstrings - bs1 > bs2');

给出

ok 74 - compare_bitstrings - bs1 > bs2

成功运行时。这告诉我我想做什么，答案应该是什么。

Answer 12

绝对!!您的单元测试应记录在每一位以及您的实际代码中。如果没有其他原因，除了不常见的情况，不知道是你的代码或你的测试是否有错误。

Answer 13

当我编写测试时，我赞成对测试的评论，然后是描述性的测试方法名称（例如在另一个答案的评论中提到的S / S / R格式），因为这是我的开发人员和我进入的习惯当我们用CP ++开始使用CPPUNIT时。当我涉足C＃时，Lucas在他的回答中提到的一点很好 - 当框架允许时，可以在源代码和结果中使用的描述字段非常方便，我赞成评论在许多地方都可以使用的格式。

所有这些，我认为您需要了解您或您的开发团队通常如何处理代码注释。当代码修复，重构时，他们是否会更新注释？项目是否更小，是否总是会有相同的少数开发人员紧密合作？

我所从事的项目规模较大，而且根据州的情况，它可能由一个团队，一个远程团队或共同开发或完全移交给供应商来维护。在我的场景中，我们会花时间在生产和测试代码中记录和维护文档，以供将来出现的人使用。

如果评论通常是经过深思熟虑的，尽管它可能会让我感到痛苦，如果你的评论有可能与实际的代码/测试一起过时，那么它可能没有意义试图改变现状。

Answer 14

我相信“如果评论无用，最好删除它”。该文档主要用于想要调用您的方法的程序员，在这种情况下，“谁将调用您的测试？”。让我们看看这个例子吗？

/// <summary>
/// Test MapRadioNameFromWave when input 104 should return "VOV English"
/// </summary>
public void Test_MapRadioNameFromWave_Input_104_ShouldReturnVOVEnglish() {
    // Test
}

但是，如果测试真的需要评论，那么肯定有必要！

我应该记录我的单元测试方法吗？

14 个答案: