我读了两个问题：（1）我们应该记录测试人员编写的单元测试和（2）我们应该如何处理假设实现细节的测试？

区分脚手架测试和单元测试很重要。（请不要被我的术语所困扰；我只是想说明一些概念。）脚手架是开发人员编写的代码，作为创建功能的一部分。它们采用开发人员希望它们采用的任何形式。它们可能是针对接口的测试。它们可能是针对不属于任何规范或要求的实现内部的测试。可能是产生通过/失败结果的测试，或者它们可能会发出只有在开发人员编码和调试时才有意义的数据块。

一旦代码正常工作，脚手架可能只是一堆垃圾。即使接口没有改变，如果脚手架假设实现细节，也不能保证或期望脚手架会做任何有用的事情。

没有人应该维护其他人的脚手架，如果他们选择保留脚手架，开发人员的工作应该是记录他们的脚手架。

单元测试（出于此答案的目的）是针对响应需求/规范的接口进行的测试。与脚手架不同，单元测试将自己限制在公共接口上。编写单元测试以产生通过/失败结果。 最重要的是，如果接口保持不变但实现发生了变化，单元测试仍然应该通过。

我认为单元测试应该有某种随附的文档。可能是代码中的注释，也可能是外部文档，尽管您需要记住，随着测试的变化，也必须有人更新外部文档。

您的测试人员提供了应该由开发人员实施的测试场景，并且您的一些开发人员编写的测试超出了要求。给他们加薪！

我建议查看额外的测试并检查它们是否有意义。鼓励所有开发人员编写更多的测试，将他们的知识投入到测试中。他们知道实现细节，因此他们可以编写更有价值的测试。他们必须确保他们的代码有效，因此他们应该有自由编写测试来证明/测试他们自己的工作。

记录这些测试，但最好只在代码中。如果测试因代码更改而失败，则更改代码的人必须修复测试、调整测试或在不再需要时将其删除。

将此视为两种不同类型的测试：测试人员使用规范从外部查看集成样式测试，开发人员使用实现细节从内部查看以证明他们的工作。

这两项测试都很重要，您应该将这两件事都强制执行。

希望能有所帮助，顺便说一句，我们这里有一句座右铭：“你触摸它，你就拥有它。” 所以无论有什么测试，都必须修复。

在传统意义上，单元测试旨在测试软件的小型功能单元，例如单个方法或功能。单元测试旨在提供对孤立的功能或方法的功能能力的有限测试。

通常，单元测试由开发人员编写和维护，因为开发人员应该在签入代码之前使用它们来验证他们的工作。单元测试在重构代码、代码改动后的初始验证以及作为开发团队在持续集成环境中的预检入套件时特别有用。

那么，要求开发人员维护单元测试（即使它们是由其他开发人员编写的）是否不公平。套用 Hunt & Thomas 的话说，“开发人员编写工作代码是有报酬的。” （在 C# 中使用 NUnit 进行实用的单元测试）并且单元测试可能有点理智，代码单元至少可以完成开发人员认为它应该做的事情。如果他们的代码未能通过单元测试，他们的更改可能会破坏构建。如果他们的代码导致单元测试过时，那么底层架构或功能可能会发生变化，作为测试人员，我想知道这一点。

与源自 BDD 方法的行为测试相比，底线单元是完全不同的工具，并且具有不同的目的。

您的一些开发人员可能正在执行 MSDN 杂志中所述的 BDD/TDD 组合方法：BDD Primer - 使用 SpecFlow 和 WatiN 的行为驱动开发。

我将 unittests 视为一种可执行文档，如果文档（=testcode）或某些生产代码（由 testcode 调用）错误，则会失败。您是否认为“如果软件文档已过时，更新它是不公平的”？

只要 Unittestmethods 具有良好的名称并且易于阅读，我认为不需要额外的文档。

我完全同意 ReneS 的回答 (+1)