在硬件便宜的时候，DB强烈的“单元测试”

Question

我正在考虑Jeff Atwood的着名文章“Hardware is Cheap, Programmers are Expensive”以及Martin Fowler的"Keep the Build Fast"推荐。

我尝试过的方法：

1. 我因为密集使用数据库而导致测试太慢。我喜欢它开始便宜..
2. 我尝试过一种带有持久傲慢易测试域对象的多层架构。我喜欢它可维护且易于使用。但就时间而言，这是昂贵的。

如果我有足够的时间资源，我通常会选择第二种方式，但大多数时候我必须选择第一种方式。

如何找到更具成本效益的方法？这是第一种使用功能强大的硬件吗？

Answer 1

触摸数据库的测试不是单元测试。

作为示例，我仅使用DB-Unit来设置集成测试的测试数据。 DB-Unit是一个很好的工具，但名称不好（包含'Unit'）。

在我们的连续集成服务器上，集成测试（也涉及DB）在正常单元测试的不同阶段运行。让不同升级级别的支票运行称为“分阶段构建”。

Answer 2

我不喜欢打击外部任何东西的单元测试，无论是数据库还是文件系统。很多人会称这些集成测试而不是单元测试。

执行速度是这类测试的问题 - 但设置速度也是如此。

您（或您团队中的任何其他人）应该能够从源代码管理中检出代码和测试并立即运行它们。他们不应该为创建数据库而烦恼。测试越难运行，它们的用处就越少。

如果您的测试具有最小的依赖性，则持续集成也会更容易。

我不认为快速硬件可以克服外部依赖性的缺点，因为磁盘和网络访问比内存访问慢得多。运行无依赖单元测试的旧机器将比必须访问磁盘和数据库的新机器更快。

至于你们两个选项之间的权衡，我认为这是一个规模问题。如果你在一个小项目中有一个程序员，那么我认为方法1）就足够了。

但是你运行的测试越多，需要运行它们的人越多，不分离你的单元和集成测试的缺点就越大。

这确实是固定成本与可变成本的问题。设置严格的单元测试可能需要一些时间，但如果您的项目足够大，您可以减少在数月内提高生产率所花费的时间。

与往常一样，这取决于项目的具体情况。祝你好运！

Answer 3

通常认为需要数据库的测试是否应称为“单元测试”。通常答案是“不”。我的意见是 - “是的”。为什么呢？

因为测试了服务方法（单位）。这些方法依赖于数据访问层，而数据访问层又依赖于数据库连接。现在，纯粹的单元测试方法是模拟依赖 - 在这种情况下是DAO。这个模拟应该相当复杂，以便按预期运行。那么为什么要创建一个复杂的模拟而不是使用内存数据库（HSQLDB / Derby / JavaDB / ..），它可以实现为运行时设置的模拟。

现在，关于问题 - 内存数据库非常（逻辑上）快速。仅此一项就可以将运行测试的时间减少到足够低的水平。

另外，我相信Continuous Integration引擎应该能够划分任务：首先制作buld（和可交付的），然后再运行测试。因此，在常见的每日案例中，您不必等待测试，而结果将很快出现，以解决任何出错的问题。