单元测试数据库方法

Question

我即将为新的Web应用程序编写单元测试。

我首选的方法是针对实时数据库结构而不是内存数据库进行测试。

我知道我可以将我的单元测试数据库调用包含在未提交的事务中。

我认为更好的方法是在初始化测试之前复制实时数据库，并允许事务提交到测试数据库。如果测试以正确的顺序运行，这将允许我通过注册第一个帐户，通过各种交互，以帐户关闭结束来创建完整的测试故事。即现实世界的生命周期。我确信这应该是一个很好的方法，但从未将其付诸实践，但我想知道在我继续之前人们是否尝试过类似的方法和反馈意见。提前谢谢。

Answer 1

我知道我会通过这样做那个人，但是让我们在此之前建立我们的条款。如果您只关心答案，请跳过此部分。

---

单元测试应该测试一个单元。它不应该依赖于外部依赖项，例如数据库，Web服务或文件系统。相反，应该模拟这些依赖关系，以便可以精确控制每个单独测试的状态。

单元测试应该是原子的，一致的和可重复的。正如John指出的那样，测试应该能够自己运行，或者每次都在具有完全相同行为的套件中运行。

集成测试应该测试组成系统的各个单元之间的交互。因此，他们永远不应该寻求存根或模拟任何依赖。这些测试应该尽可能接近测试将要部署到生产中的内容。

---

让我第一个告诉你，尽管集成测试依赖于设置和拆卸是很常见的，但在这个领域中轻轻踩。

当然，似乎是一个非常好的想法，但出于同样的原因，程序代码通常最终成为维护的噩梦，程序性测试甚至更糟。由于它们与底层代码的实现细节紧密耦合，如果您更改这些细节，最终将不得不更改大量测试。

在最好的情况下，您将丢弃大量测试并重新开始。在最糟糕的情况下，你会犹豫重构你的系统，因为你不想破坏你的测试......从而剥夺了你应该带来的优势。

我能给你的最好建议是开始阅读Acceptance Testing和Behavior Driven Development。

有些人可以提供帮助：

Gojko Adzic，Bob Martin

一些可以提供帮助的工具：

FitNesse，SpecFlow，Cucumber

请！请！请！阅读并向这些人和那些社区学习。它们将引导您朝着正确的方向前进，并帮助您避免自动化测试中的长期问题。

Answer 2

单元测试不应该依赖于它们的顺序，也不应该取决于测试的状态。他们应该建立所有必要的状态。

你所描述的可能是一个有用的测试，但它不是一组单元测试。