上下文中我们有一个MVC Web应用程序，其中包含数据库中的大量遗留代码。 （我们不允许将此代码迁移到服务器端） 对于我们的持久性商店，我们使用存储库模式。
我们的客户希望为应用程序添加新功能，因此我们显然在服务器端添加了所有新业务逻辑。
我们现在遇到的问题是我们的功能测试套件每天运行速度越来越慢。
主要原因是我们使用selenium从浏览器运行测试到数据库（端到端）。
我想知道人们是否成功使用以下其他策略：
1。摆脱用户界面
在Controller级别运行测试，而不必通过浏览器和Web服务器。为了通过UI补偿测试丢失，我们将编写javascript单元测试或MVC Views单元测试。
2。摆脱数据库
编写我们的存储库的“InMemory”版本，以便应用程序可以完全在内存中运行，这也可以加速测试套件，因为我们不会碰到磁盘而且网络更少。为了补偿，我们将为我们的数据库存储库编写集成测试。
我认为做两个1 + 2策略会产生最大速度执行，我们将测试真正重要的东西（控制器，业务层，域实体和各种帮助器作为一个整体）（我认为，UI和数据库是“细节”。）
现在，问题在于，事实上由于数据库有很多遗留代码，我不知道是否安全，只需要依靠集成测试来保持这些东西，并将数据库保留在功能测试套件之外。我应该把它放在套房里吗？还是没事？
非常感谢任何经验或建议！
我的一些调查结果如下：
答案 0 :(得分：2)
测试的持续时间越来越长。最终它会增长到你不得不放弃一些测试的程度。那是一个滑坡。
为了防止这种情况，我当然会采用1 + 2策略，但我也会保留一定数量的端到端测试。
当您添加越来越多绕过UI和DB的测试时，您可以开始决定哪些端到端测试是多余的，以及为了测试系统是否正确连接所必需的测试。
最终目标是，端到端测试是纯粹的管道测试，所有业务规则和演示行为都使用1 + 2策略进行测试。
您的存储过程是一个复杂问题。只要您不是数据库代码的更多功能，您就可以管理它。事实上，如果您可以逐步用服务器代码替换某些数据库代码，那么您将会更好。可以在不存在系统其余部分的情况下测试一些数据库代码。并且可以模拟一些数据库行为。不幸的是，也有可能只能端到端测试的行为，因此只要存在遗留数据库代码，您就可能必须保留这些测试。
这里最重要的因素是缓慢行事，避免倒退。不要开始一个巨大的项目来“修复测试”。改为逐步改进。练习“童子军规则”，总是让测试比你发现它们更好。永远不要让他们更糟一点一点地将越来越多的测试转移到策略1 + 2中。逐位替换您觉得更换的存储过程。逐步消除最冗余的端到端测试。