我想知道您的观点是否让开发人员将他们的名字或签名放在他们编写的每个测试之上以及为什么（不是）？
答案 0 :(得分：16)
我会说不。如果你真的需要知道是谁编写了测试，那么你应该能够回顾一下你的版本控制，看看谁应该受到指责。当人们开始将自己的名字放在事物上时，你会失去集体所有权/责任感，人们开始更关心“他们的”代码而不是整个系统。
答案 1 :(得分：7)
我赞成Andy的，但我还补充说，将名字放在代码中也是必须保持的其他东西。例如。 Joe创建了测试，但Jane更改了它，是Joe的测试还是Jane的测试？如果Jane不改变评论，你现在就去和Joe谈谈Jane写的代码......太令人困惑了。使用责备并完成它。
答案 2 :(得分：1)
你会对这些信息做些什么？
没有使用作者姓名的用例。
一般来说，这些信息有两种含义之一。
此人已离开（离开公司，离开项目，或承包商以及永远不会再被发现的人。）
这个人还在。
在第二种情况下，你已经知道了。将他们的名字放在源代码文件中并不能说明他们在这个代码上工作的事实，仍然在公司，仍在项目中。
因此，作者的名字没有用例。
答案 3 :(得分：1)
我赞成不言自明的测试用例而不是签名测试。
即使你知道是谁写了这个测试，并且他还在这里工作，并且他可以使用，你也无法确定他是否记得他为什么要写这个测试。
确保测试用例的名称足够明确。必要时添加评论，参考错误ID，用户故事，客户......
答案 4 :(得分：0)
我认为这取决于已经存在的态度。如果存在许多冲突，那么删除所有名称都很有用，因为代码代表了自己。但是，如果将名称放在测试中（与代码一样），那么开发人员将获得所有权。
获得所有权总是一件好事，因为它鼓励开发人员尽可能完美。当你需要询问有关测试的问题，或者测试是否失败，以及你无法弄清楚原因时，它也会有所帮助，你可以向专家询问这个问题。
然而，如果有一个更黑暗的氛围，更多关于防御的开发人员，并试图破坏对方，那么名称将使他们专注于'谁使这个代码错了'或'此测试失败，因为X编码很糟糕'而不是关注测试可能检测到的错误。
因此，在明确地将名称附加到这样的测试时总是存在平衡。 正如安迪所说，如果你真的需要知道谁写了什么，总会有源代码控制。
答案 5 :(得分：0)
我认为这实际上取决于您的文化的其余部分围绕代码所有权。如果您的团队文化是所有代码都由某人拥有，并且只有该人可以触摸该代码，那么标记其代码可能有意义。
但是，我更喜欢在拥有代码集体所有权的团队中工作。有时候在一个文件上有原创作者很好，只是为了看看它的原始设计，但除此之外，我认为标记特定测试并不有用。
正如其他人提到的，如果你真的需要弄清楚是谁做了一个特定的改变，你可以从版本控制中找出答案。但总的来说，我认为测试应由整个团队拥有和维护。