（数据库）集成测试不好吗？

 class ProductRepository
{
    private $db;

    public function __construct(ConnectionInterface $db) {
        $this->db = $db;
    }

    public function findByKeyword($keyword) {
        // this might have a query builder, keyword processing, etc. - this is
        // a totally naive example just to illustrate the DB dependency, mkay?

        return $this->db->fetch("SELECT * FROM products p"
            . " WHERE p.name LIKE :keyword", ['keyword' => $keyword]);
    }
}
 

#1 楼

编写您可以做的最小的有用测试。对于这种特殊情况，内存数据库可能会对此有所帮助。
通常可以对所有可以进行单元测试的内容进行单元测试是正确的，并且您是对的，单元测试只会让您如此远远没有了，尤其是在围绕复杂的外部服务编写简单的包装程序时。
关于测试的一种常见思考方式是作为测试金字塔。这个概念经常与敏捷相关，并且包括Martin Fowler（他将其归功于“敏捷成功”中的Mike Cohn），Alistair Scott和Google Testing Blog一起写了很多。

        /\                           --------------
       /  \        UI / End-to-End    \          /
      /----\                           \--------/
     /      \     Integration/System    \      /
    /--------\                           \----/
   /          \          Unit             \  /
  --------------                           \/
  Pyramid (good)                   Ice cream cone (bad)

概念是快速运行的弹性单元测试是测试过程的基础。应该有比系统/集成测试更集中的单元测试，以及比端到端测试更多的系统/集成测试。随着您越接近顶部，测试往往会花费更多的时间/资源来运行，往往会遭受更大的脆弱性和脆弱性的考验，并且在确定哪个系统或文件被破坏时的针对性也就更低。自然，最好避免过于繁琐。
在这一点上，集成测试还不错，但是严重依赖它们可能表明您并未将单个组件设计为易于测试的。请记住，这里的目标是测试您的单元是否在性能上达到了最低限度，同时涉及最少的其他易碎系统：您可能想尝试一个内存数据库（我将其视为对单元测试友好的测试，同时还模拟了模拟） ），例如进行繁重的案例测试，然后使用真实的数据库引擎编写一些集成测试，以确保在组装系统时主要案例可以正常工作。
正如您所指出的，测试的范围可能太狭窄：您提到编写的模拟程序只是测试某种东西的实现方式，而不是它是否有效。那是一种反模式：完美体现其测试的测试实际上根本没有测试任何东西。相反，请测试每个类或方法是否在其要求的抽象或真实级别下均根据其自身的规范进行操作。
从这种意义上说，您的方法的规范可能是以下内容之一：

发出一些任意的SQL或RPC，然后精确地返回结果
（模拟友好，但实际上并未测试您关心的查询）
准确地发出SQL查询或RPC，并精确地返回结果
/>（模拟友好，但很脆弱，并且假设在不进行测试的情况下SQL是可以的）

将SQL命令发布到类似的数据库引擎，并检查它是否返回正确的结果（在-memory-database-friendly，
也许是最好的平衡解决方案）
将SQL命令发布到您确切的数据库引擎的临时副本中，并检查是否返回正确的结果
（可能是一个很好的集成测试，但可能会易于发生基础结构
脆弱或难以确定错误）
向您的实际生产DB引擎发出一条SQL命令并检查
/>它会返回正确的结果
（对于检查已部署的行为，与＃4相同的问题可能有用，另外
修改生产数据或使服务器不堪重负的危险）

使用您的判断：选择最快，最有弹性的解决方案，该解决方案将在您需要时失败，并让您确信解决方案是正确的。

#2 楼

我的一位同事坚持认为整合测试有很多坏处，都是错误的-一切都必须经过单元测试，


这有点像说抗生素是坏的-一切都应使用维生素治疗。

单元测试无法捕获所有内容-它们仅测试组件在受控环境中的工作方式。集成测试可以验证所有东西都可以一起工作，这很难完成，但最终更有意义。

一个好的，全面的测试过程使用两种类型的测试-单元测试来验证业务规则和其他可以验证的事情。可以独立进行测试，并进行集成测试以确保一切正常。


没有真正的连接对象的集成测试，我怎么知道这实际上是在生成真正的查询-并且这些查询实际上可以执行我认为的工作？


您可以在数据库级别对其进行单元测试。使用各种参数运行查询，并查看是否获得期望的结果。授予它意味着将任何更改复制/粘贴回“ true”代码中。但它确实允许您独立于任何其他依赖项来测试查询。

#3 楼

单元测试不能解决所有缺陷。但是与其他类型的测试相比，它们设置和（重新）运行的成本更低。单元测试是通过适中的价值和低至中等的成本来证明的。

下表显示了各种测试的缺陷检出率。



来源：McConnell编写的Code Complete 2中的第470页

#4 楼

不，他们还不错。希望应该进行单元测试和集成测试。它们在开发周期的不同阶段使用和运行。

单元测试

单元代码应在编译代码后在构建服务器上和本地运行。如果任何单元测试失败，则应该使构建失败或不提交代码更新，直到修复测试为止。我们希望将单元测试隔离的原因是，我们希望构建服务器能够在没有所有依赖项的情况下运行所有​​测试。然后，我们可以运行构建，而无需所有复杂的依赖关系，并且有很多运行非常快的测试。

因此，对于数据库，应该具有以下内容：

IRespository

List<Product> GetProducts<String Size, String Color);

现在，IRepository的实际实现将进入数据库以获取产品，但对于单元测试，可以使用假的产品模拟IRepository，以在不使用actaul数据库的情况下根据需要运行所有测试，因为我们可以模拟从模拟实例返回的各种产品列表，并使用模拟数据。

集成测试

集成测试通常是边界测试。我们希望在部署服务器（真实环境），沙箱甚至本地（指向沙箱）上运行这些测试。它们不在构建服务器上运行。在将软件部署到环境之后，通常这些将作为部署后活动运行。可以通过命令行实用程序将它们自动化。例如，如果我们对要调用的所有集成测试进行了分类，则可以从命令行运行nUnit。它们实际上使用真实的数据库调用来调用真实的存储库。这些类型的测试有助于：


环境健康稳定性准备情况
测试真实物体

这些测试有时很难运行，因为我们可能还需要设置和/或拆除。考虑添加产品。我们可能想添加产品，查询它是否已添加，然后在完成后将其删除。我们不想添加100或1000个“集成”产品，因此需要进行额外的设置。

集成测试可以证明对验证环境和确保真实的环境非常有价值。事情奏效。

两者都应该有。


为每个构建运行单元测试。
为每个部署运行集成测试。

#5 楼

数据库集成测试还不错。甚至更多，它们是必需的。

您可能将应用程序划分为多个层，这是一件好事。您可以通过模拟相邻的层来隔离地测试每个层，这也是一件好事。但是，无论您创建了多少个抽象层，在某个时候都必须有一层完成肮脏的工作-实际上是在与数据库对话。除非您进行测试，否则根本不会进行测试。如果通过模拟n-1层来测试n层，则您正在评估n层在n-1起作用的条件下的假设。为了使它起作用，您必须以某种方式证明第0层有效。

虽然理论上可以通过解析和解释生成的SQL来对数据库进行单元测试，但是创建测试的方法要容易得多且更可靠

结论

对单元测试抽象存储库，Ethereal对象关系映射器，通用活动记录，理论上的持久性有何信心？层，最后生成的SQL包含语法错误吗？

#6 楼

您所引用的博客文章的作者主要关注的是集成测试可能带来的潜在复杂性（尽管它以非常有根据和明确的方式编写）。
但是，集成测试不一定是坏的，而且实际上比纯单元测试更有用。这实际上取决于应用程序的上下文以及您要测试的内容。

如果数据库服务器出现故障，今天的许多应用程序根本无法工作。至少，要在要测试的功能的上下文中考虑它。

一方面，如果要测试的内容不依赖于或无法实现完全依赖数据库，然后以甚至不尝试使用数据库的方式编写测试（只需根据需要提供模拟数据）。
例如，如果您尝试在为网页提供服务时（例如）测试一些身份验证逻辑，将其与DB分开可能是一件好事（假设您不依赖DB进行身份验证，或者您可以合理地模拟它）。 br />
另一方面，如果它是直接依赖于数据库的功能，并且在数据库不可用的情况下根本无法在实际环境中工作，则可以模拟数据库在数据库客户端中的功能代码（即使用该DB的层）不一定有意义。

例如，如果您知道您的应用程序将依赖于数据库（并且可能依赖于特定的数据库系统），那么为此而对数据库行为进行模拟通常会浪费时间。数据库引擎（尤其是RDBMS）是复杂的系统。几行SQL实际上可以执行很多工作，这很难模拟（实际上，如果您的SQL查询长几行，则可能需要更多行Java / PHP / C＃/ Python代码以在内部产生相同的结果）：复制已经在数据库中实现的逻辑是没有意义的，然后检查测试代码本身将成为问题。

我不会一定把这当作单元测试的问题集成测试，而是看待测试的范围。
单元测试和集成测试的总体问题仍然存在：您需要一套合理可行的测试数据和测试用例集，但是对于那些测试用例来说，它也足够小要快速执行的测试。

重置数据库和重新填充测试数据的时间是要考虑的一个方面；您通常会根据编写模拟代码所花费的时间（最终也必须维护）来评估它。

要考虑的另一点是应用程序对数据库的依赖程度。


如果您的应用程序仅遵循CRUD模型，那么您在其中具有一层抽象层，可以通过简单的配置设置在任何RDBMS之间进行交换，那么您很可能会能够非常轻松地使用模拟系统（可能使用内存中的RDBMS来模糊单元测试和集成测试之间的界线）。
如果您的应用程序使用更复杂的逻辑，则某些特定于SQL Server的逻辑，MySQL，PostgreSQL（例如），那么使用该特定系统进行测试通常会更有意义。

#7 楼

两者都需要。

在您的示例中，如果您要在某个条件下测试数据库，则在运行findByKeyword方法时，您会取回数据，您希望这是一种很好的集成测试。 >
在使用该findByKeyword方法的任何其他代码中，您都想控制向测试馈入的内容，因此您可以为测试返回空值或正确的单词，或者模拟数据库依赖项，等等确切知道您的测试将收到什么（并且您将失去连接数据库并确保其中数据正确的开销）

#8 楼

您认为这样的单元测试不完整是正确的。不完整在于被模拟的数据库接口中。这种天真的模拟的期望或断言是不完整的。

要使其变得完整，您必须花费足够的时间和资源来编写或集成SQL规则引擎，以确保被测对象发出的SQL语句能够实现预期的操作。

但是，通常被遗忘且昂贵的模拟替代品/同伴产品是“虚拟化”。

您能否启动一个临时的，内存中但“真实的”数据库实例用于测试单个功能？是的在那里，您有一个更好的测试，它可以检查保存和检索的实际数据。

现在，也许有人会说，您已经将单元测试变成了集成测试。关于在单元测试和集成测试之间划分界限的位置有不同的看法。恕我直言，“单位”是一个任意定义，应符合您的需求。

#9 楼

Unit Tests和Integration Tests相互正交。它们为您正在构建的应用程序提供了不同的视图。通常您都想要。但是，当您需要哪种测试时，时间点有所不同。

最常见的是Unit Tests。单元测试专注于所测试代码的一小部分-确切的称为unit留给读者。但是目的很简单：获得代码何时何地中断的快速反馈。也就是说，应该很清楚，对实际数据库的调用是一个非逻辑操作。

另一方面，有些东西只能在没有数据库的情况下进行严格的单元测试。也许您的代码中存在竞争条件，并且对DB的调用引发了对unique constraint的违反，这仅在您实际使用系统时才会抛出。但是这类测试非常昂贵，您无法（也不希望）像unit tests那样频繁地运行它们。

#10 楼

在.Net世界中，我习惯于创建一个测试项目，并创建测试来作为减去UI的双向编码/调试/测试方法。这是我发展的有效途径。我对运行每个版本的所有测试都不感兴趣（因为这确实减慢了我的开发工作流程），但我知道这样做对更大的团队有用。不过，您可以制定一个规则，即在提交代码之前，应运行并通过所有测试（如果由于实际上是在命中数据库，则测试需要更长的时间才能运行）。

模拟数据访问层（DAO）并没有真正访问数据库，不仅不允许我按照自己喜欢的方式进行编码，而且还错过了很大一部分实际代码库。如果您不是真正地测试数据访问层和数据库，而是假装，然后花大量时间进行模拟，那么我将无法掌握这种方法在实际测试代码中的用处。我正在测试一小块，而不是一次大的。我了解我的方法可能更像是集成测试，但是如果您实际上只写一次并第一次编写集成测试，那么带有模拟的单元测试似乎是浪费时间。这也是开发和调试的好方法。

实际上，一段时间以来，我已经了解了TDD和行为驱动设计（BDD），并思考了使用方法，但是很难做到这一点。追溯添加单元测试。也许我错了，但是编写一个包含更多端对端代码并包含数据库的测试似乎是一种更完整，优先级更高的测试，它涵盖了更多代码，并且是编写测试的更有效方法。 >
实际上，我认为应该采用诸如行为驱动设计（BDD）之类的方法来尝试使用领域特定语言（DSL）进行端到端测试。我们在.Net世界中拥有SpecFlow，但它始于Cucumber，是开放源代码。

https://cucumber.io/

我真的对我编写的模拟数据访问层而不访问数据库的测试的真正实用性印象深刻。返回的对象没有命中数据库，也没有填充数据。这是一个完全空的对象，我不得不以一种不自然的方式对其进行模拟。我只是觉得这很浪费时间。

根据堆栈溢出，当实际对象不适合合并到单元测试中时，可以使用模拟。

https：// stackoverflow .com / questions / 2665812 / what-is-mocking

“模拟主要用于单元测试。被测对象可能与其他（复杂）对象具有依赖性。要隔离该对象的行为您想测试用模拟真实对象行为的模拟替换其他对象。如果真实对象不适合合并到单元测试中，这将非常有用。“

我的观点是我正在端到端进行任何编码（从Web UI到业务层，从数据访问层到数据库，往返），在以开发人员身份签入任何内容之前，我将测试此往返流程。如果我从测试中切出UI并调试并测试此流程，那么我将测试UI之外的所有内容，并返回UI期望的结果。我剩下的就是向UI发送所需的内容。

我有一个更完整的测试，这是我自然开发工作流程的一部分。对我来说，那应该是最高优先级的测试，它涵盖了尽可能多地端对端实际用户规范的测试。如果我再也没有创建任何其他更详尽的测试，至少我还有一个更完整的测试，可以证明我所需的功能有效。

Stack Exchange的共同创始人不相信拥有100％单元测试覆盖率。我也不是。我将进行更完整的“集成测试”，该测试对数据库的影响超过了每天维护一堆数据库模拟的次数。

https://www.joelonsoftware.com/2009/01/31/from-podcast-38/

#11 楼

应该嘲笑外部依赖关系，因为您无法控制它们（它们可能在集成测试阶段通过但在生产中失败）。驱动器可能会失败，数据库连接可能由于多种原因而失败，可能会出现网络问题等。进行集成测试并不能给人任何额外的信心，因为它们都是运行时可能发生的问题。

使用真实的单元测试，您可以在沙盒的范围内进行测试，并且应该清楚。如果开发人员编写的SQL查询在QA / PROD中失败，则意味着他们甚至在那之前都没有测试过一次。