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

Question

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

我们的客户想要在应用程序中添加新功能，所以我们显然在服务器端添加了所有新的业务逻辑。

现在我们已经是关于其运行的每一个日子慢我们功能测试套件的问题。

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

我想，如果人们已经全成使用下面的其他战略要知道：

1.摆脱UI

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

2.摆脱DB

写我们的代码库的“InMemory”版本，以便应用程序可以在内存中完整地运行，这应该也加快测试套件，因为我们不会打磁盘和更少的网络。为了弥补，我们会为我们的数据库存储库编写集成测试。我认为这样做1 + 2策略将产生最大速度执行，我们将测试真正重要的东西（控制器，业务层，域实体和各种助手作为一个整体）（我认为，UI和数据库作为“细节”）。

现在，问题是，事实上，因为数据库有很多遗留代码，我不知道是否足够安全，只依靠这些东西的集成测试，并保持数据库脱离功能测试套件。无论如何，我是否应该将其留在套件中？还是很好？

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

---

我的一些调查结果如下：

• 连续交货书建议，这些测试应该永远是他们也说，不是每个人都同意端到端的，即使他们是缓慢的操作（虽然在那）
• 叔叔鲍勃，在我的理解，就1 + 2战略达成一致，但我不知道他是否会认为与遗留代码的数据库。

Answer 1

测试的持续时间越来越长，这是主要问题。最终它会变成一个点，你必须放弃一些测试。这是一个滑坡。为了防止这种情况发生，我当然会采用1 + 2策略，但我也会保留一定数量的端到端测试。

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

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

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

这里最重要的因素是要慢慢采取措施，避免倒退。不要开展一个庞大的项目来“修复测试”。改为逐步增量改进。练习“童子军规则”，总是让考试比你发现的要好。切勿让它们变得更糟。一点一滴地将越来越多的测试转移到策略1 + 2中。一点一点地替换您感觉舒适的替代存储过程。逐步消除最冗余的端到端测试。