记录单元测试

#1 楼

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

区分支架测试和单元测试很重要。 （请不要被我的术语所困扰；我只是想提出一些概念。）脚手架是开发人员在创建功能时编写的代码。它们采用开发人员希望采用的任何形式。它们可能是针对接口的测试。它们可能是针对实现内部的测试，而绝不是任何规范或要求的一部分。可能是产生通过/不通过结果的测试，也可能是发出仅对开发人员进行编码和调试有意义的数据的斑点。

一旦代码工作了，脚手架可能只是一堆垃圾。即使接口没有更改，如果脚手架假定了实现细节，也不能保证或期望该脚手架会做任何有用的事情。如果他们选择保留脚手架，那么开发人员的工作就是记录脚手架。

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

我认为单元测试应该有某种随附的文档。也许它是代码中的注释，或者它是一个外部文档，尽管您需要记住，随着测试的变化，也将不得不更新外部文档。

#2 楼

您的测试人员交付了应由开发人员实施的测试方案，并且您的一些开发人员编写的测试超出了要求。给他们加薪吧！

我建议检查额外的测试，并检查它们是否有意义。鼓励所有开发人员编写更多测试以将他们的知识应用于测试。他们知道实现细节，因此可以编写更有价值的测试。他们必须确保自己的代码能够正常工作，因此他们应该可以自由编写测试以证明/测试自己的工作。如果测试由于代码更改而失败，那么更改代码的人员必须修复测试，改编测试，或者在不再需要它时将其删除。

将其视为两种不同的测试：测试人员使用规格从外部指定集成样式测试，开发人员从内部使用实现细节指定内部样式测试以证明其工作。
希望有所帮助，顺便说一句，我们的座右铭是：“您触摸它，就拥有它。”因此，无论那里有什么测试，都必须修复。

#3 楼

在传统意义上，单元测试旨在测试软件的较小功能单元，例如单一方法或功能。单元测试旨在单独提供功能或方法的功能能力的有限测试。

通常，单元测试由开发人员编写和维护，因为开发人员应使用它们来限定其工作质量在检查他们的代码之前。单元测试在重构代码时，在代码搅动后进行初始验证以及作为开发团队在持续集成环境中的预检套件时特别有用。开发人员维护单元测试（即使它们是由其他开发人员编写的）。用亨特和托马斯（Hunt＆Thomas）的话来形容，“给开发人员写工作代码的报酬”。 （使用NUnit在C＃中进行实用的单元测试）单元测试可能有些理智，因为代码单元至少可以完成开发人员认为应该做的事情。如果他们的代码未通过单元测试，则其更改可能会破坏构建。如果他们的代码导致单元测试过时，则可能是基础体系结构或功能发生了变化，作为测试人员，我想知道这一点。行为测试源自BDD方法，具有不同的用途。

#4 楼

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

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

只要单元测试方法具有良好的名称并且易于阅读
，我就认为不需要过多的处理。

我完全同意ReneS的回答（+1）