作为it happens with private methods，单元测试方法文档只能由有权访问源代码的人查看。值得为此付出努力吗？
通过文档，我的意思是（但更具描述性）：
/// <summary>
///A test for SomeClass.SomeMethod
///</summary>
[TestMethod()]
public void SomeMethodTest()
{
}
【问题讨论】：
标签： unit-testing tdd
单元测试应该以自我描述为目标，但总会有无法实现这一目标的情况，因此需要对所写内容进行描述。
换句话说，尽量让你的单元测试不需要文档，但如果他们需要，那就写吧！
【讨论】：
我更倾向于说你应该以一种表达测试内容的方式来命名你的测试方法：SomeMethodWillBehaveThisWayWhenCalledWithTheseParameters() 尽管有些人可能会觉得有争议。
【讨论】：
哦，是的！
即使“有权访问源代码的人”永远不会是您以外的任何人，但在一年（甚至一个月后）看到它的人也不会是同一个，相信我那个:-)
【讨论】：
您应该记录所有代码。
对于单元测试，我通常会说我在测试什么，和它是如何测试的。放置“Test for Class.someMethod”不是很有帮助。
【讨论】：
是的。我认为记录单元测试是一个好主意的原因是，在开发过程中，如果您不仅修改生产类的 API，而且修改一些导致某些测试失败的内部行为，那么它可以节省很多时间来导航到测试代码，阅读单元测试文档，并确定考虑到您最近的行为变化，或者可能正在发生更微妙的事情，您是否预计测试会失败。
如果没有此文档，您将不得不从测试的名称和测试中的 cmets/代码中找出测试的作用。
请注意，如果您只是要在文档中重写单元测试的名称，那么这不是很有用，我会坚持只给单元测试一个描述性的名称（即文档应该是比单元测试的名称更详细）
【讨论】：
我认为记录单元测试很好，我这样做的主要原因是您可以解释为什么要测试特定功能。我的单元测试往往以各种奇怪的极端或意想不到的参数告终。
如果测试失败，未来的程序员（或者你记性不好）知道为什么要测试/实现一个功能。
【讨论】：
是的。测试似乎是自我记录的，但有时您必须通过卷积来生成有意义的测试数据，这意味着对于最终的维护者（可能就是您）来说，一切可能不会立即显而易见！让您的生活更轻松 - 记录您的代码。
【讨论】：
单元测试应该足够简单和详细，以使其易于理解。 如果你需要评论你的单元测试，也许你应该改变它的名字， 或者你应该将它重构为更小的方法。
重构测试是一种很好的做法，事实上你必须重构你的测试，否则它们将变得无法维护。
在我看来，评论几乎总是表明您应该重构需要评论的那段代码。适用于生产代码的内容适用于测试代码。
【讨论】：
大多数单元测试不需要文档。名称应该清楚地表明他们测试哪种方法并说明预期的结果。代码应该简单明了。单元测试不应该实现业务规则，因此通常不需要记录“为什么”。
在极少数情况下，测试必须足够复杂才能保证 cmets，它们应该像任何其他代码一样记录在案。
【讨论】：
对于 MSTest（如果 NUnit 有类似的东西，IDK），每个测试方法都有一个 DescriptionAttribute，因为它们显示在 Visual Studio 的测试结果面板上。比命名约定WhenThisHappenShouldHappenThis 更具可读性。
【讨论】：
我发现单元测试在运行时打印出的消息通常就足够了。例如，在 Perl 中：
is(compare_bitstrings($bs1, $bs2, $gen), 1, 'compare_bitstrings - bs1 > bs2');
给予
ok 74 - compare_bitstrings - bs1 > bs2
成功运行时。这告诉我我正在尝试做什么，以及答案应该是什么。
【讨论】：
绝对！！您的单元测试应该记录在案以及您的实际代码中。如果没有其他原因，除了不知道是您的代码还是您的测试有错误的常见情况。
【讨论】：
当我编写测试时，我喜欢为测试添加注释，然后是描述性的测试方法名称（例如另一个答案的 cmets 中提到的 S/S/R 格式），因为这是我和我的开发者伙伴养成的习惯当我们从 CPPUNIT 开始使用 C++ 时。当我涉足 C# 时，Lucas 在他的回答中提到的点是一个很好的——当框架允许时，可以在源代码和结果中使用的描述字段非常方便，我会赞成评论在很多地方都可以使用的格式。
话虽如此，我认为您需要了解您或您的开发团队通常如何处理代码 cmets。当代码被修复、重构时，人们是否在更新 cmets ？项目是否更小，是否总是有相同的少数开发人员密切合作？
我从事的项目规模较大，根据状态，它可能由紧密联系的团队、远程团队维护，或者共同开发或完全移交给供应商。在我的场景中，我们尝试花时间记录和维护生产和测试代码中的文档，以供将来出现的人使用。
如果 cmets 通常是事后才想到的，尽管这可能会让我很痛苦，但如果您的 cmets 有可能与实际代码/测试过时，那么这样做可能没有意义尝试改变现状。
【讨论】：
我相信“如果评论无用，最好删除它”。该文档主要用于想要调用您的方法的程序员，在这种情况下“谁将调用您的测试？”。我们来看看这个例子？
/// <summary>
/// Test MapRadioNameFromWave when input 104 should return "VOV English"
/// </summary>
public void Test_MapRadioNameFromWave_Input_104_ShouldReturnVOVEnglish() {
// Test
}
但如果测试真的需要评论，那肯定是必要的！
【讨论】：