数据库中的功能测试和遗留代码

Question

上下文如下，我们有一个 MVC Web 应用程序，其中数据库中有很多遗留代码。 （我们不允许将此代码迁移到服务器端） 对于我们的持久性存储，我们使用 Repository 模式。

我们的客户希望向应用程序添加新功能，因此我们显然在服务器端添加了所有新业务逻辑。

我们现在遇到的问题是关于我们的功能测试套件，它每天运行的速度越来越慢。

主要原因是我们使用 selenium 从浏览器运行测试到数据库（端到端）。

我想知道人们是否成功地使用了以下其他策略：

1.摆脱 UI

在控制器级别运行测试，而不必通过浏览器和 Web 服务器。为了弥补通过 UI 进行测试的损失，我们将编写 javascript 单元测试或 MVC 视图单元测试。

2。摆脱数据库

为我们的存储库编写一个“InMemory”版本，以便应用程序可以完全在内存中运行，这也应该加快测试套件的速度，因为我们不会撞到磁盘和更少的网络。作为补偿，我们将为我们的数据库存储库编写集成测试。

我认为执行两种 1+2 策略会产生最大的执行速度，我们将测试真正重要的东西（控制器、业务层、域实体和各种帮助器作为一个整体）（我认为，UI 和 DB 是“细节”）。

现在，问题在于，事实上，由于数据库有很多遗留代码，我不知道仅仅依靠集成测试来进行这些东西并将数据库排除在功能测试套件之外是否足够安全。我应该把它留在套房里吗？还是没问题？

任何经验或建议将不胜感激！

---

我的一些发现如下：

• 《持续交付》一书建议，这些测试应该始终是端到端的，即使它们很慢（尽管他们也说不是每个人都同意这一点）
• 据我了解，鲍勃叔叔会同意 1+2 策略，但我不确定他是否会认为使用带有遗留代码的数据库。

Answer 1

测试持续时间的延长是主要问题。最终它会增长到你必须放弃一些测试的地步。这是一个滑坡。

为了防止这种情况，我当然会采用 1+2 的策略，但我也会保持一定数量的端到端测试。

随着您添加越来越多绕过 UI 和 DB 的测试，您可以开始决定哪些端到端测试是多余的，哪些是测试系统连接正确所必需的。

最终的目标是，如果端到端测试是纯粹的管道测试，所有业务规则和演示行为都使用 1+2 策略进行测试。

您的存储过程很复杂。只要您不是数据库代码的更多功能，您就可以管理它。事实上，如果你能逐渐用服务器代码替换一些数据库代码，你会做得更好。一些数据库代码可以在系统的其余部分不存在的情况下进行测试。并且可以模拟一些数据库行为。不幸的是，也可能存在只能端到端测试的行为，因此只要遗留数据库代码存在，您就必须保留这些测试。

这里最重要的因素是慢慢来，避免倒退。不要着手一个巨大的项目来“修复测试”。而是逐步进行渐进式改进。练习“童子军规则”，总是让测试比你找到的更好。永远不要让他们变得更糟。一点一点地，将越来越多的测试转移到策略 1+2 中。一点一点地替换那些你觉得替换的存储过程。逐渐消除最冗余的端到端测试。