自动化测试的最佳实践方法

Question

这是一个非常奇怪的咨询请求，我真的觉得没有真正的答案。在我的项目中，我对用于逻辑计算的各种对象进行了归档例程，我将这些项目归档是为了进行审计跟踪，并在以后检查计算错误或证明正确性。我正在使用Entity Framework，可能与您自己的项目略有不同。

我使用原始对象，直接修改它，创建修改项的克隆，从存储恢复原始项，并相应地保存更改。如果一个对象从未被计算消耗过，那么该对象不会恢复为原始对象，在这些情况下，我直接保存在该对象上，以及与其他对象存在的各种关系。

这可能听起来像是长篇大论，但我向你保证-就我目前的情况而言，这似乎是我与EF合作最简单的一次。

我对这些归档例程的问题是，随着时间的推移，随着我引入更多的功能-我有时会在不知道的情况下破坏关键代码，以至于我必须从头到尾对整个解决方案进行回归测试，以确保归档需求保持不变。

是否有任何单元测试方法或自动化方法来测试这些类型的需求。这将加快包的部署速度，减少我自己的手动测试。

任何建议或链接到相似的情况下感谢。

Answer 1

我认为你所描述的这个问题有两个方面：

1. 首先，您需要一些可以构建的单元测试，这些测试将代表系统的技术需求。将单元测试看作是您为在技术上实现最终用户期望的目标而设置的规则。通过这种方式，我将编写单元测试，如果您对系统的技术假设由于代码更改而失败，您可以确信这些测试将会失败。请记住将单元测试保持在单元级别，这样您就不会有大量的依赖项交互而导致测试失败。单元测试应该只测试一件事。如果你这样做，当你修改代码时，你可以运行所有的单元测试，并立即知道你对系统所做的假设现在没有得到满足。
2. 我还会设置某种自动化的集成功能测试。我认为在您的问题域中，设置类似于单元测试的集成测试是有意义的(您可以使用相同的工具)。在这里，您将希望获得更大的功能块，可能是数据流经系统的管道，并测试数据上是否发生了正确的一系列转换。

Answer 2

一种最佳实践是确保测试可以以任何顺序运行。您可以将产生例程与归档例程分开，可能是通过在归档路由上使用“黄金”数据。

Answer 3

单元测试的第一个最佳实践就是直接去做！除此之外，我想推荐Gerard Meszaros的xUnit Test Patterns: Refactoring Test Code。